Checkstyle vs. PMD

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.

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.

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

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/

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

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

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

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

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

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

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.

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.

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

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>

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.

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.

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.

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