Formatowanie kodu to zła rzecz podczas korzystania z VCS?

24

Prawie zawsze formatuję kod, zanim zdecyduję się upewnić, że został on wykonany poprawnie. Większość mojego zespołu tak naprawdę nie obchodzi i nie zawsze poprawnie formatuje swój kod (drobne rzeczy, które nie wpływają na kod, ale wpływają na czytelność podczas próby jego utrzymania).

Niedawno zainstalowałem elektronarzędzia VS z opcją „Formatuj przy zapisywaniu” i wprowadziłem zmiany w pliku, który nie był wcześniej sformatowany. VP programisty właśnie do mnie przyszedł i napomniał mnie za formatowanie, ponieważ pojawia się ono w narzędziu scalającym jako zmienione prawie cały plik, a nie tylko wiersz lub dwa (więc nie widzi dokładnie tego, co łatwo zmodyfikowałem), i kazał mi wyłączyć format przy zapisywaniu w przyszłości. Rozumiem tę troskę, ale czasami trudno mi posortować kod, który jest niesformatowany, a IMO powinno i tak zawsze być odpowiednio sformatowane. Zauważ, że nie tylko zmieniam formatowanie kaprysu, ale kiedy piszę kod, albo użyję elektronarzędzia, albo uderzę klawiszem klawisza, aby sformatować tekst, aby ułatwić czytanie, a w SVN jest to wyświetlane jako modyfikacja.

Pytam więc, czy zawsze formatowanie kodu jest złą rzeczą? Czy jego obawy są ważniejsze niż upewnienie się, że kod jest czytelny?

code-formatting

— Allan Wight
źródło

8

ma rację, więc dlaczego nie zmusić całego zespołu do korzystania z narzędzia formatowania przy zapisywaniu, wtedy wszyscy otrzymacie ładnie sformatowany kod, który jest łatwy do odczytania i łatwy do przeglądania różnic zatwierdzania.

— gbjbaanb

12

Większość dobrych narzędzi do porównywania plików ma filtr „nieważne różnice” lub „ignoruj białe znaki”. Niektóre, takie jak Beyond Compare, są dostarczane z fabrycznie wbudowanymi filtrami specyficznymi dla języka. Użyj go na swoją korzyść, jeśli go masz.

— Michael K

7

Formatowanie kodu jest równie ważne, jak wprowadzone zmiany. Czytelność musi być jednym z najwyższych priorytetów w zespole. Wiceprezes powinien to wiedzieć i martwić się o to.

— Edgar Gonzalez,

@Edgar: +1. Wiceprezes jest zbyt wybredny. Najpierw czytelność ... a opcja ignorowania białych znaków oznacza, że to nie jest wielka sprawa. A to oznacza także, że jest większy problem, ponieważ reszta zespołu nie dba o to. Wiceprezes powinien być tym bardziej zaniepokojony.

— szybko_niedz.

41

Po pierwsze, Twój zespół musi wybrać konwencję formatowania i trzymać się jej. Musisz dojść do porozumienia i sprawić, by wszyscy się go trzymali, abyś nie miał ludzi walczących o to, jak powinno wyglądać. To nie powinno być coś, co robisz sam.

Co do twojego prawdziwego pytania. Formatowanie kodu nie jest złą rzeczą. Złe jest wprowadzanie poważnych zmian formatowania w tym samym zatwierdzeniu co zmiany kodu. Kiedy twój zespół dojdzie do konsensusu co do tego, jak należy sformatować rzeczy, przepuść kod i sformatuj wszystko. Sprawdź to samo. Komunikat zatwierdzenia wyjaśni, że zmiany są tylko białą spacją i nie działają. Następnie, gdy trzeba wprowadzić zmiany funkcjonalne, są one w innym zatwierdzeniu, aby były wyraźnie widoczne.

— unholysampler
źródło

nadal nie pomaga, jeśli chcesz porównać zmiany z kilku wcześniejszych wersji, ale jest lepsza niż zmiana kodu + zmiany formatu za jednym razem. Oczywiście ta odpowiedź dotyczy również refaktoryzacji.

— gbjbaanb

1

+1: Poza tym dobrze jest użyć czegoś takiego jak Stylecop lub innego narzędzia, które automatycznie formatuje i wymusza styl. Następnie zsynchronizuj ustawienia między wszystkimi członkami zespołu, aby formatowanie było spójne dla wszystkich i nie musisz koniecznie pamiętać, jaka jest „właściwa” reguła formatu.

— Ryan Hayes

3

Jeśli OP został upomniany za próbę sformatowania jednego dokumentu, coś mi mówi, że nie byłby w stanie zasugerować użycia StyleCop.

— Wayne Molina

3

@gbjbaanb: Tak. Dlatego najlepiej podejmować takie decyzje na początku. W projekcie, w którym pracuję, ustawienia repozytorium Eclipse są sprawdzone w repozytorium, dzięki czemu wiemy, że wszyscy mają te same ustawienia.

— unholysampler

1

@quickly_now: Właśnie dlatego mamy menedżerów z prawami weta. Jeśli ludzie nie mogą się zgodzić, mogą podjąć decyzję.

— unholysampler

29

Nie, kod formatujący jest bardzo ważny . Jednak zatwierdzenia powinny być wykonywane w dwóch grupach:

Zmiany kosmetyczne - wszystko, co czyni kod bardziej czytelnym.
Pozostałe zmiany - wszystko inne, co wpływa na kod.

Użyj komunikatu zatwierdzenia, aby zaznaczyć, że zmieniono tylko kosmetyki. Można je łatwo pominąć, szukając bardziej znaczących modyfikacji.

— JK
źródło

3

Ponadto dobrą praktyką jest również wybranie określonej konwencji formatowania między zespołem. Nie tylko formatuj kod innych osób bez wcześniejszego omówienia tego.

— Steven Jeuris,

Tak .. Ale wiesz, czasami kuszenie tego cholernego bałaganu jest „kuszące”, gdy jesteś przy nim. Również próba oddzielenia zmian kosmetycznych od zmian funkcjonalnych może być uciążliwa, jeśli użyjesz VS i sformatujesz coś automatycznie. Och, i nikt nie powie, że robisz głupie formatowanie, podczas gdy masz bardzo ważne zadania do wykonania, patrząc na historię

— zmian

10

Oboje macie rację, ale oboje możecie dostać to, czego chcecie. Najpierw sformatuj kod, zaznacz tylko tę zmianę. Następnie wprowadź zmiany funkcjonalne i sprawdź to jako drugi krok.

— PeterAllenWebb
źródło

3

Myślę, że to najlepsze rozwiązanie dla twojej obecnej sytuacji, ale powinieneś porozmawiać o tym ze swoim zespołem. Jednak masz większy problem, którym jest brak standardu kodowania.

— Thomas Owens

2

Zgoda. Zastanawiam się, czy środowisko PO jest jednym z tych kowbojskich miejsc, w których przestrzega się standardów, by „szybko wszystko wykończyć”.

— Wayne Molina

4

Jestem też formatującym próbnikiem nitów, więc oto kilka wskazówek:

Wymagany pierwszy krok: poproś zespół, aby zgodził się na kilka podstawowych standardów formatowania, takich jak tabulatory vs. spacje, pozycje nawiasów, style komentarzy itp. Teraz zmiany w formatowaniu nie będą dla wszystkich zaskoczeniem i nie zrobisz kroku na dowolnych palcach.
Wyczyść formatowanie tylko wokół zmienianego kodu. Jeśli wprowadzisz zmiany tylko w jednej funkcji, wyczyść tę funkcję. Przynajmniej z czasem będziesz mieć lepiej wyglądający kod.
Dokonuj poważniejszych przeglądów formatowania jako osobnego zatwierdzenia, bez żadnych innych zmian w kodzie. Powinieneś to zrobić tylko wtedy, gdy po zmianie nie będziesz chciał porównywać kodu, ponieważ porównywanie różnych różnic może być denerwujące. Zwykle robię porządki jako pierwszą rzecz przed poważnym opracowaniem tego kodu.
Uzyskaj dobre narzędzie do porównywania, które może wykonywać zależne od języka oznaczanie znaczących i nieistotnych zmian. Mój ulubiony plik różnicowy Beyond Compare oznacza rzeczywiste zmiany kodu w jednym kolorze, a różnice w białych znakach / komentarzach w innym.

edytuj, aby uzyskać jeszcze jedną wskazówkę:

Różni się w zależności od języka, ale w przypadku większości naprawdę kosmetycznych zmian w kodzie, powinieneś być w stanie porównać skompilowane pliki binarne przed i po poważnym czyszczeniu, aby mieć absolutną pewność, że go nie zniszczyłeś.

— Jan
źródło

Tak długo, jak nie dołączasz tagów VC do pliku binarnego (lub informacji o kompilacji).

— Vatine

2

Nie powinieneś ponownie formatować ani zatwierdzać zmian w kodzie innych osób, chyba że:

jesteś menedżerem próbującym ustanowić standardy kodowania zespołu
Twój menedżer poprosił Cię o wyczyszczenie kodu w celu przestrzegania standardów kodowania zespołu
czyścisz kod od programisty, który nie jest już członkiem Twojego zespołu, aby przestrzegać standardów kodowania zespołu.

Za każdym razem zauważysz, że odnoszę się do standardów kodowania zespołu. Mocno wierzę w rozsądne, uzgodnione standardy kodowania dla zespołu. Jeśli je masz, oryginalny programista powinien wrócić i wyczyścić swój kod, aby zachować zgodność ze standardami zespołu, nie powinieneś tego robić za ich plecami. Jeśli nie masz standardów (i powinieneś), nie powinieneś modyfikować kodu innego członka zespołu, aby stosować się do twoich filozofii, szczególnie za ich plecami. Pamiętaj, że należysz do zespołu i chociaż standardy kodowania są ważne, tak samo jak zaufanie i szacunek między członkami zespołu.

— cdkMoose
źródło

„Za ich plecami”: wraca to do psychologicznych kwestii własności kodu (lub wojny o rozwój).

— rwong

2

„Kod innych ludzi” to ciekawy sposób na powiedzenie tego. Pracuję nad produktem mojej firmy, skompilowanym z kodu, który jest własnością mojej firmy, nad którym pracują członkowie mojego zespołu. W żaden sposób nie jest w stanie naprawić tego standardu podczas pracy nad nim. Zgadzam się jednak, że idealnym rozwiązaniem jest doprowadzenie pierwotnego programisty do wyczyszczenia go zgodnie ze standardem.

— Caleb Huitt - cjhuitt

@Caleb: Staje się trudny, jeśli po prostu odmawiają.

— szybko_niedz.

Przez „kod innych ludzi” nie mam na myśli własności, mam na myśli coś, co napisali i wierzę, że nadal są odpowiedzialni za wsparcie. W przypadku braku standardów kodowania, jeśli zaimplementuję klasę z 1000 liniami kodu, a wprowadzisz zmiany w 2 liniach, aby poprawić niektóre zachowania i sformatować cały plik, będę bardzo zaskoczony, gdy otworzę ten plik. Jako członkowie zespołu nie powinniśmy tego robić sobie nawzajem. Jeśli sprawdzisz ten plik z pełnym przeformatowaniem, a nawet mnie nie podejmiesz, nie będzie to zbyt przyjazne dla zespołu.

— cdkMoose

W oryginalnej dyskusji OPs przeczytałem, że jest to środowisko bez kodowania standardów (lub niezbyt egzekwowane), dlatego odpowiedziałem jako takie. W takim środowisku jeden programista nie powinien narzucać swoich standardów innym.

— cdkMoose