Czy złym pomysłem byłoby okresowe uruchamianie formaterów kodu w repozytorium?

68

Zastanawiam się nad stworzeniem zadania cron, które sprawdza kod, uruchamia na nim formatery kodu, a jeśli coś się zmieni, zatwierdza zmiany i odpycha je z powrotem.

Większość projektów, które używają autoformatowania, umieszcza je w haczyku do git, ale robienie tego automatycznie co kilka godzin zmniejszyłoby obciążenie każdego dewelopera, aby zainstalować git hook.

Nadal zachęcałbym wszystkich do pisania czystego, dobrze sformatowanego kodu, i być może mogę mieć system, który automatycznie pinguje deweloperów, gdy kod, który napisali, zostanie sformatowany, aby wiedzieli, co robić w przyszłości.

duży ślepy
źródło
105
Wystąpił tutaj logiczny błąd. Ta metoda nie zachęca ludzi do pisania dobrze sformatowanego kodu; raczej zachęciłoby ludzi do nie formatowania i polegania na systemie! Jeśli martwisz się, że baza kodu jest spójna, nie ma problemu. Twoim celem jest wyszkolenie programistów do pisania w sposób czysty, to ogromny błąd.
Kilian Foth,
52
Chodzi również o rozważenie wpływu, jaki będzie to miało wpływ na takie funkcje, jak obwinianie - szczególnie jeśli formatyzator wprowadza wiele zmian, jeśli większość wierszy w pliku jest oznaczonych jako zmienione przez formater, tracisz część wartości.
Neil P
13
Mam problemy z nieprawidłową aktualizacją automatycznego formatowania i zerwaniem kodu. O czym należy pamiętać.
isaacg
22
Jeśli jest to dla Ciebie tak ważne, możesz zawieść kompilację, gdy kod nie jest poprawnie sformatowany. Jest to trochę trudne, ale odpowiednia ocena rówieśnicza zrobiłaby mniej więcej to samo.
Erno,
18
To doskonały pomysł, jeśli Twoim celem jest sprawienie, by ludzie cię nienawidzili. Osiąga bardzo niewiele, ale z pewnością spowoduje nieprzewidziane problemy.
TonyK

Odpowiedzi:

130

Brzmi nieźle, ale wolałbym mieć ludzi odpowiedzialnych za dokonywanie zmian w kodzie, a nie boty.

Poza tym chcesz mieć absolutną pewność, że te zmiany niczego nie zepsują. Na przykład mamy regułę, która porządkuje właściwości i metody alfabetycznie. Może to mieć wpływ na funkcjonalność , na przykład w kolejności danych i metod w plikach WSDL kontraktów WCF.

Marcel
źródło
50
Również trochę psuje VCS. Nie będziesz wiedział, kto z łatwością obwinił napisanie linii, a jeśli dojdzie do konfliktu, twój VCS nie będzie w stanie wiedzieć, że zmiany narzędzia dotyczą tylko stylu i powinny być odrzucane za każdym razem.
Pierre.Sassoulas,
2
Stycznie pokrewnym tematem jest wymuszanie pewnych „akcji zapisywania” w środowisku IDE, takich jak nadawanie ostateczności polom, jeśli to możliwe. Jest to problem, ponieważ (przynajmniej w Javie) wiele frameworków ustawia je poprzez odbicie (np. Spring i Hibernacja).
Captain Man,
20
@JeffO git blameto nie tylko stwierdzenie, czyj błąd jest błędem, ale także znalezienie zatwierdzenia, gdy coś zostało dodane / usunięte, co może być przydatne z wielu powodów.
Pokechu22 12.04.17
2
„mamy zasadę, która porządkuje właściwości i metody alfabetycznie” Chłopcze, to brzmi okropnie! Będziesz musiał ciągle mieć nadzieję na cały plik
Alexander
1
Również dla Javy kombinacja sprawdzania stylów, która szuka pochodnych z uzgodnionego stylu (być może nawet czyniąc go ostrzeżeniem kompilacji), oraz IDE skonfigurowane do formatowania uzgodnionego stylu sprawia, że ​​bardzo łatwo jest go wykryć i naprawić. Ważne jest, aby kod ustalał (z powodu braku lepszego słowa), kiedy faktycznie zmienia funkcjonalność - nie kiedy bot go sformatuje.
Thorbjørn Ravn Andersen
72

Zamiast tego postaram się ułatwić wszystkim członkom zespołu stosowanie automatycznego formatowania kodu zgodnie ze standardami zespołu bezpośrednio w edytorze lub środowisku IDE , do bieżącego pliku kodu źródłowego (lub wybranych jego części). Daje to członkom zespołu większą kontrolę nad tym, jak i kiedy formatowanie ma miejsce, pozwala im sprawdzić kod przed zatwierdzeniem w ostatecznej formie i przetestować go po sformatowaniu , a nie wcześniej.

Jeśli wszyscy lub większość członków zespołu korzysta z tego samego edytora, nie powinno to być zbyt trudne. Jeśli wszyscy używają innego, twoje podejście może być drugim najlepszym rozwiązaniem, o ile zespół to popiera. Jednak zalecam zainstalowanie dodatkowych środków bezpieczeństwa, takich jak nocne kompilacje i automatyczne testy uruchamiane po każdej automatycznej modyfikacji kodu.

Doktor Brown
źródło
7
„Formater pod ręką, w którym masz 100% pewności, że niczego nie zepsuje” - Kiedy kiedykolwiek natrafiłeś na fragment kodu , który był, szczerze mówiąc, w 100% pewien, że nigdy się nie zepsuje?
Zibbobz
2
@Zibbobz: dowolne narzędzie, którego używamy do edycji kodu, kompilowania i łączenia go, a także VCS, może zawierać błędy, ale to nie powstrzymuje nas przed próbą opracowania działających programów ;-) Ale zobacz moją edycję.
Doc Brown
Popieram edycję - choćby dlatego, że dodatkowa uncja ostrożności jest warta funta debugowania. ;)
Zibbobz
@Zibbobz Dość często! Zauważ, że 100% pewność czegoś nie oznacza, że ​​ma 100% szansy na bycie prawdziwym.
immibis
@immibis: mogłeś nie zauważyć, że komentarz dotyczył zdania, które usunąłem z mojej odpowiedzi kilka dni temu.
Doc Brown
37

To zły pomysł, nie tylko dlatego, że zniechęca ludzi do pisania przyzwoitego kodu, ale także dlatego, że formatowanie pojawi się wraz ze zmianami kodu w twoim VCS (mam nadzieję, że używasz takiego), maskując historyczny przebieg rozwoju kodu. Co gorsza, każda czynność formatowania kodu (a właściwie każda zmiana kodu) ma możliwość wprowadzenia błędów, zarówno ręcznych, jak i automatycznych. Twój formatyzator może teraz wprowadzać błędy w kodzie, które nie będą poddawane przeglądom kodu, testom jednostkowym, testom integracji itp., A być może miesiące później.

jwenting
źródło
10
Myślę, że jeśli mówi o tym, że bot sprawdza rzeczy w repozytorium i poza nim, VCS jest oczywiste?
StarWeaver
11
@StarWeaver można by pomyśleć. Pracowałem jednak w miejscach, w których „repozytorium kodu” było chronionym katalogiem dostępnym tylko dla oprogramowania działającego pod jego własnym kontem użytkownika, bez kontroli wersji poza cotygodniową kopią zapasową katalogu pod nazwą katalogu ze znacznikiem czasu.
jwenting 12.04.17
14
To… Idę teraz na koszmary>.>
StarWeaver
7
@StarWeaver, jak myślisz, dlaczego nadal pamiętam to środowisko 14 lat później;)
jwenting
28

Chciałbym wierzyć, że to dobry pomysł (automatyczne uruchamianie formaterów kodu), ale to tylko moja opinia.

Nie będę ich uruchamiał okresowo, ale jeśli to możliwe, zanim przejdzie kontrola wersji.

Z git , o pre-commit robi to byłoby użyteczne. W wielu projektach C lub C ++ zbudowanych przy użyciu jakiegoś Makefile dodam jakiś indentcel (który odpowiednio uruchamia formatery kodu, takie jak indentlub astyle) i oczekuję, że współtwórcy będą działali make indentregularnie. BTW, możesz nawet dodać kilka makereguł, aby upewnić się, że haki git zostały zainstalowane (lub je zainstalować).

Ale tak naprawdę jest to bardziej kwestia społeczna niż techniczna . Chcesz, aby Twój zespół popełnił czysty i ładnie sformatowany kod, co jest społeczną zasadą Twojego projektu. (Nie zawsze istnieje techniczna odpowiedź na każdy problem społeczny).

Kontrola wersji to przede wszystkim narzędzie pomagające w komunikacji między twórcami oprogramowania (w tym również za kilka miesięcy od samego siebie). Twoje oprogramowanie nie potrzebuje VC ani formatowania, ale Twój zespół tego potrzebuje.

BTW, różne społeczności i różne języki programowania mają różne poglądy na temat formatowania kodu. Na przykład Go ma tylko jeden styl formatowania kodu, ale C lub C ++ mają ich wiele.

Basile Starynkevitch
źródło
Tak, ale to oznacza, że ​​każdy programista musi zainstalować hook zatwierdzenia.
bigblind
17
Tak, ale jest to reguła społeczna i potrzebujesz kilku z nich. Nie można znaleźć technicznego rozwiązania każdego problemu społecznego. Musisz przekonać ludzi. Ponadto każdy programista musi zainstalować kompilator i sam system kontroli wersji.
Basile Starynkevitch
Zgadza się, więc mówisz, że społeczna zasada instalowania git hook jest lepsza niż zautomatyzowany system, który to robi? (poważne pytanie, nie rozumiane jako retoryczne, ton jest trudny do przekazania w Internecie :))
bigblind
15
Tak, mówię to.
Basile Starynkevitch 12.04.17
17

Myślę, że to zły pomysł. Wiele odpowiedzi już zawierało informacje, że brudzi historię, utrudniając ustalenie, kto tak naprawdę dodał linię, i zachęca ludzi do popełniania cokolwiek, a format-bot sobie z tym poradzi.

Lepszym rozwiązaniem byłoby włączenie kontrolera formatu do narzędzia do kompilacji. (W Javie jest Checkstyle ). Pozwól więc na łączenie swoich gałęzi z gałęzią główną tylko wtedy, gdy kompilacja przejdzie (łącznie z formatowaniem).

Jeśli pozwalasz ludziom na zatwierdzanie bezpośrednio do głównej gałęzi (jak na przykład w Subversion), nadal będziesz musiał upewnić się, że wszyscy mają dyscyplinę do zatwierdzania tylko sformatowanego kodu (lub że serwer akceptuje zatwierdzenia dopiero po uruchomieniu niektórych kontroli) ).

Kapitanie Człowieku
źródło
2
ale upewnij się, że sprawdzanie stylu jest rozsądne i nie wymusza dziwnych rzeczy, które są sprzeczne z wszelkimi zaakceptowanymi (i akceptowalnymi) praktykami (i tak, widziałem takie). Możesz także ustawić serwer kompilacji na niepowodzenie automatycznej kompilacji, gdy moduł sprawdzania stylu zgłasza (nowe) błędy.
jwenting 14.04.17
2
Widziałem wiele przypadków, w których automatyczne formatowanie wytwarza nieczytelny kod. Zwłaszcza w przypadku wielu zamykających się części (rozsądne jest pozostawienie niektórych z nich na osobnych liniach, ale robota to nie obchodzi). Innym przykładem jest automatyczne dzielenie długich ciągów Java (są one długie, ponieważ zawierają zapytania SQL, ale robot nie ma pojęcia).
18446744073709551615
@ 18446744073709551615 Nie sugeruję automatycznego formatowania, sugeruję automatyczne sprawdzanie . Twoje zasady mogą na to pozwolić.
Captain Man
16

Ogólnie uważam, że to zły pomysł. Zasadniczo jest to słuszny pomysł, ale w rzeczywistości może być problematyczny. Zepsucie kodu przez formatyzator kodu jest realną możliwością, a programiści potrzebują tylko jednego uruchomienia formatowania, aby programiści odpowiedzieli z (prawdopodobnie uzasadnioną) wrogością (np. „Twój kiepski formatyzator kodu złamał kompilację, wyłącz ją teraz! ).

Podobnie jak zalecenie @ BasileStarynkevitch, używamy haków po odbiorze po stronie serwera git, aby wysyłać „e-maile z poradami” na temat stylu kodu.

Jeśli wypchnę zatwierdzenie zawierające naruszenia stylu, serwer pochodzenia git wyśle ​​mi wiadomość e-mail z informacją, że złamałem wytyczne dotyczące stylu i zalecam naprawienie mojego kodu. Nie wymusza tego jednak, ponieważ mogą istnieć uzasadnione powody do przełamania stylu domu (na przykład długie łańcuchy przekraczające limit długości linii).

Jeśli jest to problem systemowy, który szkodzi bazie kodu, być może nadszedł czas, aby zacząć wyświetlać problemy ze stylem kodu w recenzjach kodu. Zły styl kodu może maskować błędy i utrudniać odczytanie kodu, więc może to być ważny problem z przeglądaniem kodu.

Aby dodać aspekt „problemu społecznego” rzeczy, warto zachęcać ludzi do usuwania defektów kosmetycznych i stylistycznych w miarę ich znajdowania. Mamy standardowy komunikat zatwierdzenia „Kosmetyk”. dla poprawek stylu kodu, o których wiedzą inni programiści, nie zawierają przełamujących zmian.

Jak mówi @DocBrown, inną opcją jest wymuszenie stylu kodu w twoim IDE. Używamy CodeMaid z Visual Studio, aby poprawić wiele typowych błędów stylu. Będzie działał po zapisaniu plików kodu, co oznacza, że ​​kod w złym stylu nigdy nie powinien nawet dostać się do repozytorium ... teoretycznie :-).

Karl Nicoll
źródło
Głosowałem za tym, ponieważ bezpośrednio odnosi się do obu stron (chęć lepszego kodu + bezpieczeństwo po zerwaniu kompilacji). Po tym, jak baza kodu jest w naprawdę dobrym stanie, uważam, że „zły pomysł” jest dość mocnym sformułowaniem do automatyzacji przyszłych zmian.
donjuedo
10

Tak, myślę, że to zły pomysł. Nie zrozum mnie źle, powód, aby to zrobić, brzmi świetnie, ale wynik może być nadal okropny.

Będziesz miał konflikty scalania podczas ciągnięcia śledzonej gałęzi, przynajmniej obawiam się, że tak byłoby, ale mogę się mylić.

Nie chcę tego teraz testować w pracy, ale powinieneś sam go wypróbować.

W rzeczywistości możesz po prostu sprawdzić ostatnie zatwierdzenie. Stwórz nowy oddział, popełnij coś drobnego, wybierz wiśni lub połącz bez automatycznego zatwierdzania.

Następnie uruchom skrypt, pociągnij, a jeśli twój wynik jest okropnym bałaganem scalania, zdecydowanie nie rób tego, za dnia.

Zamiast tego możesz potencjalnie umieścić go w kompilacji nocnej lub tygodniowej.

Ale nawet nocleg może być złym pomysłem.

Możesz albo uruchamiać go co tydzień, gdy masz pewność, że nie wystąpią konflikty scalania, ponieważ wszystko jest zakończone w poniedziałek.

W przeciwnym razie uruchom go 1-2 razy w roku w okresie wakacyjnym, gdy nie dojdzie do konfliktów scalania.

Ale rozwiązanie może zależeć od priorytetu stylu kodu.

Myślę, że lepiej byłoby stworzyć skrypt instalacyjny, który automatycznie utworzy repozytorium git i ustawi haki dla projektu.

Lub możesz dołączyć skrypt konfiguracyjny hook do folderu dla deweloperów w projekcie i po prostu sprawdzić go w git.

Mam nadzieję, że jest pomocna
źródło
7

Coś, o czym nie wspomniałem, to fakt, że czasami istnieją uzasadnione powody, aby nie formatować czegoś zgodnie z zestawem reguł. Czasami poprawia się przejrzystość kodu, postępując w sprzeczności z wytycznymi, które 99% czasu ma sens. Ludzie muszą wykonać to połączenie. W takich przypadkach automatyczne formatowanie kodu skończyłoby się, czyniąc rzeczy mniej czytelnymi.

Andy Lester
źródło
Kompletnie się zgadzam. Na przykład wyrównanie identyfikatorów zmiennych po lewej stronie, wszystkich znaków równości w jednej kolumnie i wszystkich wartości po prawej stronie znaków równości. Formatyzator zmniejszyłby czytelność w tym przypadku, zmniejszając tabulatory / spacje do pojedynczych spacji. Oczywiście reguły formatera mogą zostać napisane, aby temu zapobiec, ale wtedy potrzebujesz programisty przypisanego do pisania formatera kodu. Wszystko wokół wydaje się złym pomysłem. Przyjmij lepsze konwencje wewnętrzne i egzekwuj je podczas przeglądania kodu.
ThisClark 15.04.17
7

To okropny pomysł.

Jeśli jeden z moich kolegów programistów wprowadzi nieuzasadnione zmiany w plikach źródłowych, nie przejdzie przeglądu kodu. To po prostu utrudnia życie wszystkim. Zmień kod, który wymaga zmiany, nic więcej. Bezcelowe zmiany prowadzą do konfliktów scalania, które mogą prowadzić do błędów i po prostu tworzyć bezcelową pracę.

Jeśli chcesz to robić regularnie, to po prostu okropne.

Następnie pojawia się pytanie, jakie zmiany wprowadza formater kodu. Używam automatycznego formatowania w moim edytorze, działa dość dobrze i mogę poprawić rzeczy, gdy automatyczne formatowanie jest mniej niż idealne. Jeśli użyjesz formatowania kodu, który wykracza poza to, nie poprawisz kodu, pogorszysz go.

A potem jest problem społeczny. Są ludzie, którzy chcą zmusić wszystkich do korzystania ze swojego stylu kodu, i są bardziej elastyczni ludzie. Coś takiego mogłoby sugerować programista „grammer-nazi” (celowe pisownia), który chce narzucić swój styl wszystkim innym. Spodziewaj się luzu i spodziewaj się, że elastyczni, zwykle bezproblemowi programiści oprą się.

gnasher729
źródło
4

Nie wspominasz o używanym VCS, ale zależnie od tej innej opcji jest przechwycenie po stronie serwera. Obsługuje to VCS jak git. Można zainstalować haczyk po stronie serwera, który uruchamia formatyzator na wypychanej wersji, a następnie porównuje sformatowany plik z wypychaną wersją. Jeśli się różnią, programista nie zastosował poprawnego formatowania, a serwer może odrzucić wypychanie. Zmusiłoby to twoich programistów do wypychania kodu tylko z pożądanym formatowaniem, zachęcając ich do pisania czystego kodu od samego początku, sprawiłoby, że twórcy byliby odpowiedzialni za przetestowanie poprawnie sformatowanego kodu i odciążyliby programistów od konieczności ręcznej instalacji po stronie klienta hak.

sigy
źródło
To właśnie robi Go, z wyjątkiem używania Mercurial. Pchanie czegoś, co nie jest niezmienne, go fmtjest automatycznie odrzucane.
Jörg W Mittag
1

Jest to kompromis między czystszym formatem kodu a dokładniejszą i łatwiejszą do zrozumienia historią git. Zależy od charakteru twojego projektu i tego, jak często nurkujesz w historii git lub obwiniasz, aby zrozumieć, co się dzieje. Jeśli pracujesz nad czymś nowym i nie musisz zachowywać kompatybilności wstecznej, historia zwykle nie odgrywa tak istotnej roli.

Max Yankov
źródło
1

Ten pomysł jest podobny do niektórych innych odpowiedzi, ale nie mogę komentować moich sugestii.

Jedną z opcji jest ustawienie aliasu (lub przechwytywania, lub cokolwiek innego) dla funkcji zatwierdzania, która uruchamia formater kodu na kodzie do zatwierdzenia przed zatwierdzeniem.

Może mieć 2 (lub więcej) wyników:

1) Pokaż użytkownikowi proponowane zmiany i poproś o zgodę na ich zastosowanie i zatwierdzenie.

2) Zignoruj ​​proponowane zmiany i zatwierdź oryginalny kod.

Możesz również dodać większą elastyczność do tych opcji, na przykład możliwość edycji zmian zaproponowanych w opcji 1. Innym pomysłem (w zależności od tego, jak bardzo chcesz przeforsować te standardy kodowania) jest przesłanie przez system pewnego rodzaju raportu, gdy wybrano opcję 2.

Może to stanowić dobrą równowagę między automatycznym sprawdzaniem całego kodu, jak chcesz, a jednocześnie zapewniać elastyczność programistom w zależności od ich potrzeb. Pozwala również na opcję nie „automatycznego odrzucania” kodu z różnicami w formatowaniu, jak wspomniano w innych odpowiedziach. Za pomocą „Przejrzałem i zatwierdzam automatyczne korekty formatowania; opcja commit, nadal utrzymuje osobistą odpowiedzialność za pracę każdego programisty i nie zadziera z VCS.

MadisonCooper
źródło
0

Nie zrobię tego w repozytorium, ale zrobię to przy zapisie, jeśli narzędzie to obsługuje. Eclipse jest jednym z nich, a ponadto wykonałbym czyszczenie kodu, w tym sortowanie.

Zaletą jest to, że jest to część projektu, więc każdy programista otrzyma go za swój projekt.

Jako dodatkowy bonus połączenia zostałyby znacznie uproszczone, ponieważ rzeczy nie będą się przeskakiwać.

Recenzje kodu zapobiegną błędom.

Innym miejscem, w którym bym to zrobił, jest włączenie go do kompilacji. W moim przypadku mam takie, że kompilacje maven przeformatują XML i wyczyszczą pliki pom i sformatują kod.

W ten sposób, gdy programiści będą gotowi do wypychania, wszystko zostanie oczyszczone z ich żądania ściągnięcia.

Archimedes Trajano
źródło