Checkstyle vs. PMD

86

Wprowadzamy narzędzia do analizy statycznej do systemu kompilacji naszego produktu Java. Używamy Maven2, więc integracja Checkstyle i PMD jest bezpłatna. Wygląda jednak na to, że funkcjonalność tych dwóch narzędzi w dużym stopniu pokrywa się pod względem egzekwowania podstawowych zasad stylu.

Czy korzystanie z obu tych opcji przynosi korzyści? Nie chcę utrzymywać dwóch narzędzi, jeśli jedno będzie działać. Jeśli wybierzemy jeden, którego powinniśmy użyć i dlaczego?

Planujemy również użyć FindBugs. Czy są inne narzędzia do analizy statycznej, którym powinniśmy się przyjrzeć?

Aktualizacja: Wydaje się, że konsensus jest taki, że PMD jest preferowane w stosunku do CheckStyle. Nie widzę solidnego powodu, aby używać obu i nie chcę utrzymywać 2 zestawów plików reguł, więc prawdopodobnie będziemy dążyć wyłącznie do PMD. Wprowadzimy również FindBugs i być może ostatecznie Mackera, aby wymusić reguły architektoniczne.

John Stauffer
źródło

Odpowiedzi:

71

Zdecydowanie powinieneś używać FindBugs . Z mojego doświadczenia wynika, że ​​odsetek wyników fałszywie pozytywnych jest bardzo niski i nawet najmniej krytyczne ostrzeżenia, które zgłasza, są warte do pewnego stopnia uwzględnienia.

Jeśli chodzi o Checkstyle w porównaniu z PMD, nie użyłbym Checkstyle, ponieważ dotyczy on tylko stylu. Z mojego doświadczenia wynika, że ​​Checkstyle będzie zgłaszać mnóstwo rzeczy, które są zupełnie nieistotne. Z drugiej strony PMD jest również w stanie wskazać wątpliwe praktyki kodowania, a jego wynik jest ogólnie bardziej odpowiedni i przydatny.

Chris Vest
źródło
49
+1 za dodanie rekomendacji FindBugs. Jednak zdecydowanie nie zgadzam się z twoją opinią na temat Checkstyle, chyba że jesteś deweloperem samotnym wilkiem z własnym, specyficznym stylem. W przypadku zespołów uzgodnienie wspólnego, rozsądnego podzbioru reguł, a następnie użycie zautomatyzowanego narzędzia, takiego jak Checkstyle do automatycznego egzekwowania ich, skutkuje otrzymaniem kodu czytelnego dla wszystkich.
John Tobler
1
Chociaż nie jest doskonały, FindBugs jest zdecydowanie najlepszy. PMD i Checkstyle wskazują na wręcz złe praktyki. Należy ich unikać za wszelką cenę, chyba że bardzo dobrze wiesz, które ostrzeżenia są ważne, a które nie.
DPM
Co dziwne, miałem dokładnie odwrotne doświadczenie z PMD vs Checkstyle. PMD często zgłasza fałszywe alarmy, jeśli jest to coś, czego nie znaleziono w stylu checkstyle lub Findbugs. Jednak 7 lat może mieć duże znaczenie.
xenoterracide
38

Oba programy są przydatne. Checkstyle pomoże Ci podczas programowania, sprawdzając styl kodowania, np. Nawiasy klamrowe, nazewnictwo itp. Proste rzeczy, ale bardzo liczne!

PMD pomoże Ci, sprawdzając bardziej skomplikowane zasady, takie jak podczas projektowania Twoich zajęć, lub w przypadku bardziej specjalnych problemów, takich jak poprawna implementacja funkcji klonowania. Po prostu PMD sprawdzi Twój styl programowania

Jednak oba programy cierpią z powodu podobnych reguł, czasami źle wyjaśnionych. Przy złej konfiguracji możesz sprawdzić dwa lub dwie przeciwne rzeczy, np. „Usuń bezużyteczne konstruktory” i „Zawsze jeden konstruktor”.

ROMANIA_engineer
źródło
10
Dokładnie. IMHO, to 2 narzędzia mające na celu robienie różnych rzeczy, więc nie jestem pewien, czy są one w ogóle porównywalne. Jeśli chcesz wymusić standardowy styl kodowania w zespole programistycznym, użyj Checkstyle. Jeśli chcesz przeanalizować kod pod kątem problemów projektowych lub złych praktyk kodowania, użyj PMD.
aberrant 80
24

Jeśli wybierzemy jeden, którego powinniśmy użyć i dlaczego?

Narzędzia te nie są konkurencyjne, ale uzupełniają się i powinny być używane jednocześnie.

Typ konwencji (Checkstyle) to klej, który umożliwia ludziom wspólną pracę i uwolnienie ich kreatywności, zamiast tracić czas i energię na rozumienie niespójnego kodu.

Przykłady Checkstyle:

  • Czy istnieje javadoc w metodach publicznych?
  • Czy projekt jest zgodny z konwencjami nazewnictwa firmy Sun?
  • Czy kod jest napisany w spójnym formacie?

podczas gdy PMD przypomina złe praktyki:

  • Łapanie wyjątków bez robienia czegokolwiek
  • Mając martwy kod
  • Zbyt wiele złożonych metod
  • Bezpośrednie użycie implementacji zamiast interfejsów
  • Implementacja metody hashcode () bez metody not equals (Object)

źródło: http://www.sonarsource.org/what-makes-checkstyle-pmd-findbugs-and-macker-complementary/

Lucas
źródło
1
Zgadzam się, że Checkstyle, bardziej skupia się na formacie kodu i zmusza programistę do przestrzegania „standardu kodu”, ale może też wykryć wiele złych praktyk, spójrz tutaj , a rozszerzenie Checkstyle jest łatwiejsze do rozwoju, ale zgadzam się że ma ograniczenia i nigdy nie pokona PMD i FindBug.
Roman Iwanow
15

Używamy obu:

  • Checkstyle, aby upewnić się, że wszyscy w zespole piszą kod w podobny sposób
  • PMD, aby znaleźć problematyczne obszary kodu i następne cele refaktoryzacji
Ilya Kochetov
źródło
7

Jeśli Twoim głównym miejscem użytkowania jest programowanie w zaćmieniu, najlepiej sprawdzi się CodePro firmy Instantiations. Wcześniej było to narzędzie komercyjne, ale teraz Google kupiło instancje, więc CodePro analytix jest teraz bezpłatne.

Sprawdź http://code.google.com/javadevtools/download-codepro.html

Naveen
źródło
7

Jeśli przejrzałeś listy reguł Checkstyle, PMD i Findbugs, zobaczyłeś, że wszystkie trzy zapewniają wartościowe wyniki, a wszystkie trzy do pewnego stopnia pokrywają się, a także wprowadzają własne, unikalne reguły do ​​tabeli. Dlatego narzędzia takie jak Sonar używają wszystkich trzech.

To powiedziawszy, Findbugs ma najbardziej szczegółowe lub niszowe zasady (np. „Wątpliwe wychwytywanie IllegalMonitorStateException” - jak często możesz się z tym spotkać?), Więc jest użyteczny z niewielką konfiguracją lub bez niej, a jego ostrzeżenia należy traktować poważnie. W przypadku Checkstyle i PMD reguły są bardziej ogólne i związane ze stylami, więc powinny być używane tylko z niestandardowymi plikami konfiguracyjnymi, aby uchronić zespół przed lawiną nieistotnych opinii („Tab char on line 5”, „Tab char on line 6”, "Tab char on line 7" ... masz obrazek). Zapewniają również potężne narzędzia do pisania własnych zaawansowanych reguł, np. Reguła Checkstyle DescendentToken .

Podczas korzystania ze wszystkich trzech (szczególnie z narzędziem takim jak Sonar), wszystkie z nich należy skonfigurować osobno (omówienie wszystkich reguł zajmuje co najmniej kilka dni), zwracając uwagę, aby zapobiec duplikacji (wszystkie trzy narzędzia wykrywają, że hashCode () został overridden i equals () not, na przykład).

Podsumowując, jeśli uważasz, że statyczna analiza kodu jest cenna, odrzucanie wartości któregokolwiek z trzech nie ma sensu, ale aby użyć wszystkich trzech, musisz poświęcić czas na ich skonfigurowanie, aby uzyskać użyteczną informację zwrotną.

Tomislav Nakic-Alfirevic
źródło
6

Sonar (http://www.sonarsource.org/) to bardzo użyteczna otwarta platforma do zarządzania jakością kodu, która zawiera Checkstyle, PMD, Findbugs i wiele więcej.

Oznacza to również, że wszystkie 3 narzędzia mają swoje prawo do istnienia ...

DaveFar
źródło
5

Oba narzędzia są konfigurowalne i mogą robić prawie te same rzeczy. To powiedziawszy, jeśli mówimy o rzeczach nieszablonowych, wiele się pokrywa, ale istnieją również odrębne zasady / kontrole. Na przykład Checkstyle ma silniejsze wsparcie dla sprawdzania Javadoc i znajdowania magicznych liczb, żeby nazwać parę. Dodatkowo Checkstyle posiada funkcję „kontroli importu”, która wygląda podobnie do funkcjonalności Mackera (nie używałem Mackera).

Jeśli są dla Ciebie ważne rzeczy, które Checkstyle robi od razu, a PMD nie, możesz rozważyć minimalną konfigurację Checkstyle z tylko tymi kontrolami. Następnie wprowadź zasadę, że konfiguracja Checkstyle nie może się rozwijać, po prostu usuń kontrole, wdrażając podobną funkcjonalność z, powiedzmy, niestandardowymi regułami PMD.

Weź również pod uwagę, że jeśli zdecydujesz, że funkcja „kontroli importu” Checkstyle obejmuje to, czego oczekujesz od Mackera, możesz zaimplementować PMD / Checkstyle zamiast PMD / Macker. Tak czy inaczej są to dwa narzędzia, ale z Checkstyle dostaniesz rzeczy, których PMD nie robi od razu „za darmo”.

Greg Mattes
źródło
5

Checkstyle i PMD sprawdzają się dobrze w sprawdzaniu standardów kodowania i są łatwe do rozszerzenia. Jednak PMD ma dodatkowe zasady sprawdzania cyklicznej złożoności, złożoności Npath itp., Które pozwalają pisać zdrowy kod.

Kolejną zaletą korzystania z PMD jest CPD (Copy / Paste Detector), który wykrywa powielanie kodu w projektach i nie jest ograniczony do JAVA, działa również dla JSP. Neal Ford ma dobrą prezentację na temat Metrics Driven Agile Development , która mówi o wielu narzędziach pomocnych w programowaniu Java / Java EE

Arjan Tijms
źródło
4
Dla każdego, kto czyta to ... checkstyle ma teraz następujące checkstyle.sourceforge.net/config_metrics.html checkstyle.sourceforge.net/config_duplicates.html
smp7d
4

Uważam, że Checkstyle i PMD są najlepsze do wymuszania problemów ze stylem i prostych oczywistych błędów kodowania. Chociaż odkryłem, że lubię używać Eclipse i wszystkie ostrzeżenia, które zapewnia, lepiej w tym celu. Egzekwujemy rzeczy, używając wspólnych preferencji i oznaczając je jako rzeczywiste błędy. W ten sposób nigdy nie są odprawiani.

To, co gorąco i entuzjastycznie polecam, to używanie FindBugs. Ponieważ działa na poziomie kodu bajtowego, może sprawdzać rzeczy, które są niemożliwe na poziomie źródła. Chociaż wypluwa sporą część śmieci, znalazł wiele aktualnych i ważnych błędów w naszym kodzie.

Alex Miller
źródło
4

A 10 lat później ... W 2018 używam ich wszystkich Checkstyle, PMD i FindBugs.

Zacznij od FindBugs . Może później dodaj PMD i Checkstyle.

Nigdy na ślepo nie egzekwuj domyślnych zasad !

Kroki:

  • uruchom jedno narzędzie z domyślnymi regułami w projekcie, który ma dużo kodu
  • dostosuj reguły do ​​tego projektu, zakomentuj niepotrzebne reguły z notatkami
  • skoncentruj się na nisko wiszących regułach owoców (NPE, kontrole rejestratorów, niezamknięte kontrole zasobów, ...)
  • wykonaj kilka poprawek dla zasad, które uznasz za wartościowe (pojedynczo!)
  • zrób to dla każdego narzędzia, ale nie dla wszystkich naraz!
  • powtórz ten proces

W idealnym przypadku każdy projekt może mieć oddzielne zasady. Lubię uruchamiać reguły za pośrednictwem kompilacji (za pomocą wtyczek maven) i zawodzić w przypadku błędów reguł, gdy wiem, że projekt spełnia wszystkie zdefiniowane przeze mnie reguły. Zmusza to programistów do podejmowania działań, ponieważ raportowanie nie wystarczy . Od tego momentu Twój projekt jest prawie kuloodporny, a później możesz nawet dodać więcej reguł i / lub napisać reguły niestandardowe.

Christophe Roussy
źródło
FYI, SpotBugs jest „duchowym następcą FindBugs” , a dokumentacja SpotBugs jest całkiem niezła. O ile wiem, FindBugs nie był aktualizowany od lat.
skomisa
Nigdy nie słyszałem o SpotBugs, prawdopodobnie dlatego, że FindBugs + fbcontrib wystarczyło na długi czas, dobrze wiedzieć, że jest jakiś zamiennik
Christophe Roussy
Dyskusja na ten temat jest tutaj: news.ycombinator.com/item?id=12885549
Christophe Roussy
Warto również zauważyć, że narzędzia mają zwykle konfigurowalną czułość. Np. Zaczynając od FindBugs / SpotBugs, może być konieczne wybranie wysokiego progu, aby wyłapać tylko najpoważniejsze błędy, a następnie obniżanie progu w miarę naprawiania rzeczy.
ThrawnCA
@ThrawnCA tak, ale nawet z wrażliwością: w dużym projekcie zostanie znalezionych zbyt wiele błędów, które można naprawić w rozsądnym czasie. Więc zamiast tego dodaję jedną regułę na raz, zaczynając od najniższych wiszących owoców, takich jak potencjalne wykrywanie NP, a następnie przechodzę do reguł, takich jak niezamknięte zasoby.
Christophe Roussy
3

Jedną kwestią, której do tej pory nie widziałem, jest to, że istnieją wtyczki dla IDE, które będą wymuszać zestawy reguł CheckStyle w twoim kodzie, podczas gdy wtyczki PMD będą zgłaszać tylko naruszenia. Na przykład w projekcie obejmującym wiele lokalizacji w kilku zespołach programistycznych ważne jest, aby aktywnie egzekwować standardy, a nie tylko raportować na ich temat.

Oba narzędzia mają dostępne wtyczki dla IntelliJ, NetBeans i Eclipse (moim zdaniem obejmuje to większość zastosowań). Nie jestem zaznajomiony z NetBeans, więc mogę komentować tylko IntelliJ i Eclipse.

W każdym razie wtyczki PMD dla IntelliJ i Eclipse będą generować raporty na żądanie dotyczące naruszeń PMD w ramach kodu projektu.

Z drugiej strony wtyczki CheckStyle będą podświetlać naruszenia w locie i mogą (przynajmniej w przypadku IntelliJ, mam mniejsze doświadczenie z Eclipse) być skonfigurowane tak, aby automatycznie konwertować niektóre problemy (np. Dla „OneStatementPerLine”, umieści CR-LF między instrukcjami, dla 'NeedBraces', doda nawiasy klamrowe tam, gdzie ich brakuje itp.). Oczywiście tylko prostsze naruszenia można naprawić automatycznie, ale nadal jest to pomoc w przypadku starszych projektów lub projektów zlokalizowanych w kilku lokalizacjach.

„Na żądanie” w przypadku PMD oznacza, że ​​deweloper musi świadomie zdecydować o uruchomieniu raportu. Natomiast naruszenia Checkstyle są automatycznie zgłaszane do nich w miarę ich rozwoju. Choć PMD nie zawierają szerszą zestaw reguł, w moim umyśle automatyczne enforecement / zgłaszania naruszeń w IDE jest warta kłopotów z utrzymaniem 2 zestawy zasad.

Więc dla wszelkich projektów nad którymi pracuję, używamy zarówno narzędzia, Checkstyle egzekwowane w IDE, PMD zgłaszane w IDE i oba zgłoszone i mierzy się buduje (poprzez Jenkins).

GKelly
źródło
1
Istnieją również sposoby na zintegrowanie go z kompilacją i uniemożliwienie jej niepowodzenia w przypadku naruszenia (na przykład z maven). Zrobiłem to dla Checkstyle, PMD i FindBugs. Jak powiedziałeś, raportowanie nie wystarczy.
Christophe Roussy
3

Spójrz na qulice-maven-plugin, który łączy ze sobą Checkstyle, PMD, FindBugs i kilka innych analizatorów statycznych i wstępnie je konfiguruje. Piękno tej kombinacji polega na tym, że nie trzeba ich konfigurować indywidualnie w każdym projekcie:

<plugin>
  <groupId>com.qulice</groupId>
  <artifactId>qulice-maven-plugin</artifactId>
  <version>0.15</version>
  <executions>
    <execution>
      <goals>
        <goal>check</goal>
      </goals>
    </execution>
  </executions>
</plugin>
yegor256
źródło
Jak skonfigurować, aby uzyskać raport (w jakimś użytecznym formacie)? Teraz tylko wypluwa go na konsolę, nawet jeśli skonfiguruję log4j. Widzę, że istnieje raport o błędzie, który może być powiązany, ale nie jestem pewien.
Adam Arold
Myślimy tak samo, ale aby to naprawić, muszę to zaznaczyć w moim kodzie lub coś podobnego. Przynajmniej settings.jarpomogłeś.
Adam Arold
2

Powtórzę komentarz, że PMD jest bardziej aktualnym produktem do sprawdzania stylu / konwencji Java. Jeśli chodzi o FindBugs, wiele komercyjnych grup programistycznych korzysta z Coverity.

Steve Moyer
źródło
1

PMD jest tym, do czego odnosi się więcej osób. Checkstyle było tym, o czym ludzie mówili 4 lata temu, ale uważam, że PMD jest utrzymywane w bardziej ciągły sposób i jakie inne IDE / wtyczki wybierają do pracy.

anjanb
źródło
2
To prawda w 2008 roku, ale dzisiaj Checkstyle nabrał ogromnej szybkości.
barfuin
1

Właśnie zacząłem używać Checkstyle i PMD. Dla mnie PMD jest łatwiejsze do tworzenia niestandardowych reguł dla rzeczy, takich jak to, czy istnieje System.gc (), Runtime.gc (), o ile możesz napisać zapytanie XPath, co również nie jest wcale trudne. Jednak PMD nie pokazał mi, że ma funkcję pokazywania numeru kolumny. Więc w przypadku takich rzeczy, jak sprawdź limity kolumn. Możesz chcieć użyć Checkstyle.

JP
źródło
-2

PMD to najlepsze narzędzie w porównaniu ze stylami kratki. Checkstyles może nie mieć możliwości analizy kodu, podczas gdy PMD oferuje wiele funkcji do tego! Offcourse PMD nie opublikowało reguł dotyczących javadoc, komentarzy, wcięć itp. A tak przy okazji, planuję wdrożyć te zasady ...... dzięki

janasainik
źródło
Jedną z dobrych rzeczy o Checkstyle to pozwala trochę elastyczne reguły jak RegexpSingleline ...
Jigar Shah