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.
źródło
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”.
źródło
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:
podczas gdy PMD przypomina złe praktyki:
źródło: http://www.sonarsource.org/what-makes-checkstyle-pmd-findbugs-and-macker-complementary/
źródło
Używamy obu:
źródło
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
źródło
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ą.
źródło
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 ...
źródło
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”.
źródło
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
źródło
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.
źródło
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:
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.
źródło
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).
źródło
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>
źródło
settings.jar
pomogłeś.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.
źródło
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.
źródło
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.
źródło
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
źródło