Czy można modyfikować format innego kodu programisty podczas modyfikowania / dodawania do modułu?

Rozwijając się w atmosferze grupowej i dodając lub modyfikując funkcje w jakiejś bazie kodu. Czy przeformułowanie poprzedniego kodu programisty w celu dostosowania go do obecnych standardów kodowania jest uważane za obraźliwe czy niegrzeczne? Rozumiem, że standardy się zmieniły i prawdopodobnie będą się zmieniać, ale czy ktokolwiek z was poczuje się urażony, jeśli ktoś przejdzie i zmieni formatowanie kodu?

Żeby było jasne, nie mówię o zmianie logiki, po prostu bałaganiu się tabulatorami i spacjami itp.

EDYCJA: Robię to nie tylko ze względu na standardy kodowania, ale pomaga mi czytać ich kod i aktualizować go, dzięki czemu mogę w pełni zrozumieć logikę, która została zaimplementowana, zanim zacznę modyfikować krytyczne aplikacje.

Myślę, że jest to OK, o ile uzgodnione zostaną standardy. Jedna uwaga jednak; pamiętaj, że istnieje możliwość, że plik jest modyfikowany przez innych w tym samym czasie. Jeśli utrudnisz ich scalanie tylko dlatego, że zmieniałeś formatowanie, nie będziesz bardzo popularny.

Tak, kod powinien należeć do projektu. Dostosowanie kodu do standardu pomoże zmniejszyć deficyt techniczny projektu. Jeśli go modyfikujesz, jesteś za to odpowiedzialny. W przypadku starszego kodu pierwotny programista może już nie być w projekcie lub mieć nowe obowiązki.

Po dokonaniu tego rodzaju zmiany dobrze jest przeprowadzić testy weryfikacyjne po ponownym sformatowaniu. Jeśli przejdą, sprawdź kod przed dokonaniem zmian funkcji.

EDYCJA: W kontekście tego pytania właściwe jest przeformatowanie do standardu. W przypadku braku standardów zalecałbym zalecanie standardów i nie formatowanie, dopóki nie będą standardów dla formatu. Ponowne formatowanie zgodnie z osobistym gustem / standardami nie powinno odbywać się za pomocą kodu należącego do projektu.

Uważam, że zawsze dobrą praktyką jest refaktoryzacja kodu podczas modyfikacji / dodawania do określonego pliku. Obejmuje to aktualizację stylu kodu w celu odzwierciedlenia odpowiednich konwencji nazewnictwa dla zmiennych / metod i stylów kodowania.

Robię to cały czas. Stary kod powinien być zgodny z tymi samymi standardami co nowy kod, a jeśli nie naprawisz go podczas pracy, nikt tego nie zrobi. Myślę, że to się liczy zgodnie z regułą skautową.

Myślę, że to dobra praktyka i niezbędna część konserwacji kodu.

Poleciłbym sprawdzenie zmian formatowania w jednym zatwierdzeniu w systemie kontroli wersji oraz zmian funkcjonalnych w osobnym zatwierdzeniu, aby pomóc sobie i innym zrozumieć, co się wydarzyło.

Nie miałbym z tym żadnego problemu i prawdopodobnie doceniłbym to ... o ile zmiany nie są „religijne”. Proszę nie przechodź przez wszystkie moje klasy i przenieś nawiasy klamrowe do pierwszego wiersza metody. Jeśli formatowanie jest uzasadnionym typem „różnych pociągnięć dla różnych ludzi”, to jest trochę denerwujące, gdy ktoś wchodzi i nakłada format na kod, który najczęściej edytujesz. Jeśli jednak zostaniesz głównym edytorem tego konkretnego modułu, wprowadź odpowiednie zmiany formatowania.

Tak. „Napraw” kod według własnego uznania. Tak jak mówią pragmatyczni programiści w swojej książce The Pragmatic Programmer , nie ma zepsutych okien. Jeśli kod nie jest równy, uważam, że jest to rozbite okno.

Istnieją różne repozytoria, które automatycznie dokonają formatowania podczas odprawy, a także drobne rzeczy, takie jak zmiana parowania CR / LF po uzyskaniu, w zależności od platformy, z której pochodzi źródło.

Tworzenie własnych formatów ma ogromną wadę polegającą na tym, że mnóstwo zmian formatowania zostanie zaciemnionych, a jeśli wystąpi problem z regresją, trudniej będzie znaleźć szkodliwe bloki kodu.

Możesz zasugerować swojemu tropowi, że skoro podstawa kodu jest stara, powinna zostać przeniesiona z zimna i przeformatowana do aktualnych standardów za jednym zamachem, prowadząc do świetlanej nowej przyszłości wszędzie.

Ponieważ mówisz o czysto „formatowaniu” (co oznacza, że ​​nie naprawiamy błędów, ale wyglądamy ładnie według twojego standardu), myślę, że to zależy, czy oryginalna osoba nadal utrzymuje kod, czy nie.

Jeśli pomysłodawca nadal pracuje nad projektem - jest niegrzeczny. To, co może „wyglądać” dla ciebie, nie jest tym, co „będzie wyglądać” dla nich, a modyfikowanie kodu w celu formatowania nie jest uprzejme. Może także marnować dużo czasu.

Pracowałem kiedyś nad projektem z BARDZO zaborczym programistą. Przez lata opracowałem bardzo metodyczny sposób formatowania mojego kodu, który moim zdaniem jest łatwy do odczytania, mniej podatny na ukryte błędy i samodokumentowanie. Ten facet, z drugiej strony, faworyzował użycie wszystkich ukrytych funkcji z długimi liniami o szerokości 300 znaków, więc trzeba było mieć 30-calowy monitor, aby go odczytać, ponieważ uważał, że liczba linii jest ważniejsza niż czytelność. Spędził pół dnia przeglądając mój kod, zmieniając go na „preferowany standard” ... kiedy wciąż się rozwijałem równolegle! Przyszedłem następnego ranka, by znaleźć dwa dni pracy sformatowane na jego bałagan. To było niegrzeczne i strata czasu.

Teraz, jeśli programista zniknął i masz „lepszy styl”, idź po niego.

Zawsze formatuj kod automatycznie, jeśli Twoje IDE może to zrobić.

• Zapobiega ręcznym zmianom formatowania, które nie zaśmiecają historii wersji na dłuższą metę
• Profil programisty musi zostać uzgodniony przez wszystkich programistów (wybrać domyślny? -)
• Ustaw kod formatowania i organizuj importowanie nawyku podczas zapisywania pliku

Na przykład w środowisku Eclipse można najpierw uruchomić formatyzator i zorganizować importowanie całej bazy kodu. Następnie pamiętaj, aby przed zapisaniem ctrl + alt + f.