Automatyczne sprawdzanie plików Java pod kątem zgodności z kodowaniem standardowym

Question

Pracuję nad programowaniem w języku Java. Niedawno doszedłem do sytuacji, w której muszę przestrzegać standardów kodowania: porządkowanie członków i metod, konwencje nazewnictwa, sekwencje modyfikatorów. Zastanawiam się nad metodami zautomatyzowania sprawdzania zgodności lub wygenerowania jakiegoś mechanizmu, który zmienia kolejność.

Pracujemy z Eclipse, ale technologia będzie otwarta. Jednym ze sposobów, w jaki może działać, jest generowanie zewnętrznego narzędzia do budowania i dodawanie go do projektów. Wadą byłoby to, że automagicznie zastosowałby się do wszystkich plików, które mogłyby napotkać problemy ze starszym kodem, zwiększając liczbę błędów do stopnia, w którym nie jest już rozsądnym wskaźnikiem zgodności. Ponadto sprawia, że ​​recenzje kodu są znacznie trudniejsze, co nie jest pożądane.

Innym sposobem byłoby coś w rodzaju parsera z jedynie informacyjnymi możliwościami. Moglibyśmy uruchomić proces wewnątrz Jenkinsa, a to z pewnością zadziałałoby, ale to również oznaczałoby, że kod przeszedł już przegląd, który zwykle jest trochę spóźniony na sprawdzenie zgodności kodu.

Czy istnieją sugerowane, a nawet łatwe metody włączenia takich funkcji do IDE, systemu kontroli źródła (Mercurial), a nawet Jenkins? Jak to jest egzekwowane w innym miejscu?

Answer 1

nie polecam robić takich zmian automatycznie. Mimo że większość z checkstyle/pmd jest zgodna, zdarza mi się, że muszę zignorować niektóre ostrzeżenia/błędy. Co więcej - istnieje tylko bardzo mała pula takich łatwych problemów. Większość powiadomień wymaga bardziej skomplikowanych operacji i prawdopodobnie nie można tego zrobić bez interakcji z innymi użytkownikami.

Używam integracji Sonar. Zawiera wiele zewnętrznych kontrolerów, takich jak PMD, CPD, Checkstyle, Findbugs i może łączyć się z innymi przydatnymi narzędziami, takimi jak Cobertura (statystyki zasięgu testu). Jego niemal banalne powiązanie z budową Sonara do budowy Jenkinsa i próba uniknięcia poważnych/krytycznych problemów może być uważane za dobre podejście.

W środowisku programistów używam integracji Eclipse z findbugami. Istnieje również pewien punkt integracji z sonarem, ale wymaga to przesłania kodu do serwera lub lokalnego serwera, którego osobiście nie lubię. Jednak po kilku cyklach polerowania kodu po recenzji kodu w Sonarze zauważysz, że ty (i inni członkowie zespołu) trzymasz się większości zasad i codziennie sprawdzasz raporty.

Answer 2

Jednym z rozwiązań jest użycie JCSC/checkstyle lub innych narzędzi przyjaznych dla linii poleceń. Zintegruj to z procesem budowania. Indywidualny programista uruchamia to w swoim oddziale.

Większość narzędzi integrować dobrze Jenkins (za pośrednictwem wtyczek), które mogą być używane jako deskę rozdzielczą

Answer 3

W odpowiedzi na @ Jayana, Jenkins ma CheckStyle plugin, który wyświetli wyniki każdego uruchomienia CheckStyle i pozwoli ci ustawić status kompilacji w zależności od tego, ile wykrytych naruszeń. Więc twoje kroki konfiguracji będzie:

1. Skonfiguruj CheckStyle rules do swoich standardów kodowania
2. Dodaj krok do budowania Jenkins, który biegnie Checkstyle
3. Dodaj krok po kompilacji do publikowania wyników Checkstyle.

Answer 4

Jayan wymienia checkstyle, który doskonale nadaje się do sprawdzania standardów kodowania.

Pamiętam, że za pomocą Jalopy lat temu zautomatyzowane formatowanie kodu, może również odpowiadać twoim potrzebom.

Jednak szczerze mówiąc, nie przeformułowałbym kodu automatycznie. Używanie takich narzędzi jak checkstyle do podnoszenia ostrzeżeń to jedno. Przejęcie kontroli nad kodem źródłowym programisty jest czymś zupełnie innym, a większość ludzi uważa to za okropnie inwazyjne i nieprzyjemne. Ponadto, błąd w module sprawdzania kodu w najgorszym razie wygeneruje nieprawidłowe ostrzeżenia. Błąd w kodzie upiększającym może zepsuć i zniszczyć godziny pracy.

Answer 5

Można użyć JArchitect sprawdzić swoje najlepsze praktyki przy użyciu zapytań CQLinq która jest przydatna stworzyć w łatwy Twoje zasady niestandardowe

JArchitect jest bezpłatny dla otwartych autorów źródło: http://www.jarchitect.com/JArchitectForOSS.aspx