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

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.

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.

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.

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.

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.

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

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 :-).

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.

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.

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

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.

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.

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.

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.