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

13

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.

wfoster
źródło
6
Włącz automatyczne „formatowanie przy zapisie” dla wszystkich. Wszyscy używają tych samych uzgodnionych ustawień. Po chwili cały kod jest znormalizowany.
1
Może być punkt, w którym to idzie za daleko. Miałem współpracownika, który sformatował wszystko, dodając przełamania linii, które nie były potrzebne, a nawet istotne, o ile mnie to dotyczyło. Osobiście, chyba że jest to nieczytelne lub kod stał się moją główną odpowiedzialnością, pozostawiam formatowanie w spokoju, chyba że wprowadzę inne zmiany.
SoylentGray
1
Jeśli piszesz w c #, to trzymaj się StyleCop. Jeśli w innych językach, spróbuj wybrać dobre, bezstronne narzędzie.
Job
5
Czy to „Jestem zmianę formatowania ... bo ja myślę powinien wyglądać inaczej” .. czy jest to „ja zmieniając formatowanie ... zbyt pasuje do normy ” ... niezwykle różne pytania
WernerCD
1
@Thorbjorn Nie rozważałbym gałęzi, która naprawiałaby formatowanie w każdym pliku, 1 plik na zatwierdzenie, historię zabijania. Jednak naprawienie go podczas tego samego zatwierdzenia jest po prostu złe. (Wydaje mi się, że mogliby użyć czegoś takiego jak git addselektywne zatwierdzanie części, ale domyślam się, że większość ludzi używa odpowiednika svn commitlub git commit -a)
alternatywny

Odpowiedzi:

19

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.

Jeremy Mullin
źródło
10
Pierwsze zdanie tutaj jest ważne. Upewnij się, że faktycznie przestrzegasz uzgodnionych standardów, a nie tylko wprowadzasz zmiany, ponieważ je lubisz.
Thomas Owens
5

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.

BillThor
źródło
2
+1 za „sprawdź kod przed wprowadzeniem zmian w funkcji”
bdoughan
1
+1 ponownie dla „sprawdź zmiany formatowania przed dokonaniem zmian funkcji” i „dobrze jest uruchomić testy weryfikacyjne po ponownym sformatowaniu”. Najlepiej byłoby, gdybyśmy przeprowadzali testy weryfikacyjne przed każdym zameldowaniem.
leed25d
W rzeczywistości to, czy sformatujesz przed czy po zmianach, tak naprawdę nie ma znaczenia. Liczy się to, że łatki estetyczne powinny być oddzielone od łatek funkcjonalnych -> jeśli łatka estetyczna zmieniła funkcjonalność, nie była zamierzona i może być uznana za błąd; ułatwia przeglądanie łat funkcjonalnych (ponieważ jest mniejszy).
Matthieu M.,
@Matthiew M: Prawda, ale w większości przypadków zostaną one wykonane w celu poprawy konserwacji przed konserwacją. Niewielu programistów ma na to czas po fakcie. Ponadto, jeśli kod musi zostać zaktualizowany, aby przejść automatyczne testy odprawy, należy go najpierw sformatować, aby zachować separację poprawek estetycznych i funkcjonalnych.
BillThor,
3

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.

Wayne Molina
źródło
OP poprosił o sformatowanie, a nie refaktoryzację.
quant_dev
Wiem; Powiedziałem, że uważam, że obejmuje to również ponowne formatowanie :)
Wayne Molina,
2

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ą.

RKitty
źródło
2

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.

semaj
źródło
1
+1 za osobne zatwierdzenia. Próba ustalenia, jakie zmiany kodu zostały wprowadzone w zatwierdzeniu, gdy kod został przeformatowany w tym samym czasie, jest PITA. Twoje narzędzia porównywania są bezużyteczne, jeśli każda linia w pliku uległa zmianie.
Dave Kirby
2

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.

Morgan Herlocker
źródło
1

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.

mpenrow
źródło
1

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.

Patrick Hughes
źródło
1

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.

Jordan Parmer
źródło
0

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.

jkj
źródło