Checkstyle vs. PMD

85

Wir führen statische Analysetools in das Build-System für unser Java-Produkt ein. Wir verwenden Maven2, daher ist die Integration von Checkstyle und PMD kostenlos. Es sieht jedoch so aus, als ob sich die Funktionalität dieser beiden Tools hinsichtlich der Durchsetzung grundlegender Stilregeln stark überschneidet.

Gibt es einen Vorteil, wenn beide verwendet werden? Ich möchte nicht 2 Tools warten, wenn eines funktioniert. Wenn wir eine auswählen, welche sollten wir verwenden und warum?

Wir planen auch die Verwendung von FindBugs. Gibt es andere statische Analysewerkzeuge, die wir uns ansehen sollten?

Update: Konsens scheint zu sein, dass PMD CheckStyle vorgezogen wird. Ich sehe keinen soliden Grund, beides zu verwenden, und ich möchte nicht zwei Sätze von Regeldateien verwalten, daher werden wir wahrscheinlich ausschließlich PMD anstreben. Wir werden auch FindBugs und möglicherweise Macker einbringen, um Architekturregeln durchzusetzen.

John Stauffer
quelle

Antworten:

69

Sie sollten auf jeden Fall FindBugs verwenden . Nach meiner Erfahrung ist die Falsch-Positiv-Rate sehr niedrig, und selbst die am wenigsten kritischen Warnungen, die gemeldet werden, sind bis zu einem gewissen Grad wert.

Was Checkstyle vs. PMD betrifft, würde ich Checkstyle nicht verwenden, da es so ziemlich nur um Stil geht. Nach meiner Erfahrung wird Checkstyle über eine Menge Dinge berichten, die völlig irrelevant sind. Andererseits kann PMD auch auf fragwürdige Codierungspraktiken hinweisen, und seine Ausgabe ist im Allgemeinen relevanter und nützlicher.

Chris Vest
quelle
48
+1 für das Hinzufügen Ihrer Empfehlung von FindBugs. Ich stimme Ihrer Meinung zu Checkstyle jedoch überhaupt nicht zu, es sei denn, Sie sind ein Einzelgänger-Entwickler mit Ihrem eigenen eigenwilligen Stil. Für Teams führt die Vereinbarung einer gemeinsamen vernünftigen Teilmenge von Regeln und die Verwendung eines automatisierten Tools wie Checkstyle zur automatischen Durchsetzung dieser Regeln zu Code, der von allen gelesen werden kann.
John Tobler
1
FindBugs ist zwar nicht perfekt, aber bei weitem das Beste. PMD und Checkstyle weisen Sie auf geradezu schlechte Praktiken hin. Um jeden Preis zu vermeiden, es sei denn, Sie wissen genau, welche Warnungen gültig sind und welche nicht.
DPM
Seltsamerweise habe ich genau das Gegenteil von PMD gegen Checkstyle gemacht. PMD meldet häufig falsch positive Ergebnisse, wenn es sich um einen Checkstyle handelt oder Findbugs nicht gefunden hat. 7 Jahre können jedoch sehr wichtig sein.
Xenoterracide
38

Beide Softwareprogramme sind nützlich. Checkstyle hilft Ihnen bei der Programmierung, indem es Ihren Codierungsstil überprüft, z. B. geschweifte Klammern, Namen usw. Einfache Dinge, aber sehr zahlreich!

PMD hilft Ihnen dabei, kompliziertere Regeln wie beim Entwerfen Ihrer Klassen oder bei spezielleren Problemen wie der korrekten Implementierung der Klonfunktion zu überprüfen. PMD überprüft einfach Ihren Programmierstil

Beide Softwareprodukte leiden jedoch unter ähnlichen Regeln, die manchmal schlecht erklärt werden. Bei einer schlechten Konfiguration können Sie zwei oder zwei entgegengesetzte Dinge überprüfen, z. B. "Nutzlose Konstruktoren entfernen" und "Immer einen Konstruktor".

ROMANIA_engineer
quelle
9
Genau. IMHO, es sind 2 Tools, die darauf abzielen, verschiedene Dinge zu tun, also bin ich mir nicht sicher, ob sie überhaupt vergleichbar sind. Wenn Sie einen Standardcodierungsstil in einem Entwicklungsteam erzwingen möchten, verwenden Sie Checkstyle. Wenn Sie Code auf Entwurfsprobleme oder schlechte Codierungspraktiken analysieren möchten, verwenden Sie PMD.
aberrant80
24

Wenn wir eine auswählen, welche sollten wir verwenden und warum?

Diese Tools konkurrieren nicht miteinander, ergänzen sich jedoch und sollten gleichzeitig verwendet werden.

Der Konventionstyp (Checkstyle) ist der Klebstoff, mit dem Menschen zusammenarbeiten und ihre Kreativität freisetzen können, anstatt Zeit und Energie für das Verständnis inkonsistenten Codes aufzuwenden.

Checkstyle-Beispiele:

  • Gibt es Javadoc über öffentliche Methoden?
  • Entspricht das Projekt den Namenskonventionen von Sun?
  • Ist der Code in einem einheitlichen Format geschrieben?

während PMD Sie an schlechte Praktiken erinnert:

  • Eine Ausnahme abfangen, ohne etwas zu tun
  • Toten Code haben
  • Zu viele komplexe Methoden
  • Direkte Verwendung von Implementierungen anstelle von Schnittstellen
  • Implementieren der hashcode () -Methode ohne die ungleiche (Object object) -Methode

Quelle: http://www.sonarsource.org/what-makes-checkstyle-pmd-findbugs-and-macker-complementary/

Lucas
quelle
1
Ich bin damit einverstanden, dass Checkstyle, der sich mehr auf das Codeformat konzentriert und Entwickler dazu zwingt, dem "Code-Standard" zu folgen, aber auch viele schlechte Praktiken erkennen kann. Schauen Sie hier , und die Erweiterung von Checkstyle ist für die Entwicklung einfacher, aber ich stimme zu dass es Einschränkungen hat und PMD und FindBug niemals überwinden wird.
Roman Ivanov
15

Wir verwenden beide:

  • Überprüfen Sie den Stil, um sicherzustellen, dass jeder im Team Code auf ähnliche Weise schreibt
  • PMD, um problematische Codebereiche und nächste Refactoring-Ziele zu finden
Ilya Kochetov
quelle
7

Wenn Ihr Hauptverwendungsort die Entwicklung in Eclipse ist, ist CodePro von Instantiations am besten geeignet. Früher war es ein kommerzielles Tool, aber jetzt hat Google Instantiations gekauft, sodass CodePro analytix jetzt kostenlos ist.

Überprüfen Sie http://code.google.com/javadevtools/download-codepro.html

Naveen
quelle
7

Wenn Sie die Checkstyle-, PMD- und Findbugs-Regellisten überprüft haben, haben Sie festgestellt, dass alle drei wertvolle Ergebnisse liefern und sich alle drei bis zu einem gewissen Grad überschneiden und auch ihre eigenen, eindeutigen Regeln in die Tabelle aufnehmen. Aus diesem Grund verwenden Tools wie Sonar alle drei.

Trotzdem hat Findbugs die spezifischsten oder Nischenregeln (z. B. "Zweifelhaftes Abfangen von IllegalMonitorStateException" - wie oft werden Sie wahrscheinlich darauf stoßen?), So dass es mit wenig oder keiner Konfiguration verwendet werden kann und seine Warnungen ernst genommen werden sollten. Bei Checkstyle und PMD sind die Regeln allgemeiner und stilbezogener, sodass sie nur mit benutzerdefinierten Konfigurationsdateien verwendet werden sollten, um das Team vor einer Lawine irrelevanten Feedbacks zu bewahren ("Tab char in Zeile 5", "Tab char in Zeile 6"). "Tab char in Zeile 7" ... Sie erhalten das Bild). Sie bieten auch leistungsstarke Tools zum Schreiben eigener erweiterter Regeln, z. B. die Checkstyle DescendentToken- Regel.

Wenn Sie alle drei verwenden (insbesondere mit einem Tool wie Sonar), sollten alle separat konfiguriert werden (es dauert mindestens einige Tage, um alle Regeln abzudecken), und Sie müssen darauf achten, dass keine Duplikate auftreten (alle drei Tools erkennen, dass hashCode () vorhanden ist überschrieben und gleich () zum Beispiel nicht).

Zusammenfassend lässt sich sagen, dass es keinen Sinn macht, den Wert abzulehnen, wenn Sie die statische Code-Analyse für wertvoll halten. Um alle drei zu verwenden, müssen Sie Zeit investieren, um sie zu konfigurieren und Ihnen brauchbares Feedback zu geben.

Tomislav Nakic-Alfirevic
quelle
6

Sonar (http://www.sonarsource.org/) ist eine sehr nützliche offene Plattform zur Verwaltung der Codequalität und umfasst Checkstyle, PMD, Findbugs und vieles mehr.

Dies zeigt auch an, dass alle 3 Tools ihr Existenzrecht haben ...

DaveFar
quelle
5

Beide Tools sind konfigurierbar und können fast das Gleiche tun. Das heißt, wenn wir über Out-of-the-Box-Produkte sprechen, gibt es viele Überschneidungen, aber es gibt auch unterschiedliche Regeln / Überprüfungen. Zum Beispiel hat Checkstyle eine stärkere Unterstützung für das Überprüfen von Javadoc und das Finden magischer Zahlen, um nur einige zu nennen. Zusätzlich hat Checkstyle eine "Import Control" -Funktion, die der Funktionalität von Macker ähnelt (ich habe Macker nicht verwendet).

Wenn es Dinge gibt, die für Sie wichtig sind, die Checkstyle sofort ausführt, die PMD nicht tut, können Sie eine minimale Checkstyle-Konfiguration mit nur diesen Überprüfungen in Betracht ziehen. Richten Sie dann eine Richtlinie ein, die die Checkstyle-Konfiguration nicht erweitern kann. Entfernen Sie einfach Überprüfungen, wenn Sie ähnliche Funktionen beispielsweise mit benutzerdefinierten PMD-Regeln implementieren.

Denken Sie auch daran, dass Sie PMD / Checkstyle anstelle von PMD / Macker implementieren können, wenn Sie entscheiden, dass die Checkstyle-Funktion "Import Control" das abdeckt, was Sie von Macker wollten. In beiden Fällen handelt es sich um zwei Tools, aber mit Checkstyle erhalten Sie das, was PMD nicht "kostenlos" sofort einsatzbereit macht.

Greg Mattes
quelle
5

Checkstyle und PMD können beide Codierungsstandards gut überprüfen und sind einfach zu erweitern. PMD verfügt jedoch über zusätzliche Regeln zur Überprüfung der zyklomatischen Komplexität, der Npath-Komplexität usw., mit denen Sie fehlerfreien Code schreiben können.

Ein weiterer Vorteil der Verwendung von PMD ist CPD (Copy / Paste Detector). Es ermittelt die Duplizierung von Code über Projekte hinweg und ist nicht auf JAVA beschränkt. Es funktioniert auch für JSP. Neal Ford hat eine gute Präsentation zu Metrics Driven Agile Development , in der viele Tools vorgestellt werden, die für die Java / Java EE-Entwicklung hilfreich sind

Arjan Tijms
quelle
4

Ich finde, Checkstyle und PMD eignen sich am besten zur Durchsetzung von Stilproblemen und einfachen offensichtlichen Codierungsfehlern. Obwohl ich festgestellt habe, dass ich Eclipse und alle Warnungen gerne verwende, ist es für diesen Zweck besser geeignet. Wir erzwingen Inhalte, indem wir gemeinsame Einstellungen verwenden und diese als tatsächliche Fehler markieren. Auf diese Weise werden sie überhaupt nicht eingecheckt.

Was ich nachdrücklich und enthusiastisch empfehlen würde, ist die Verwendung von FindBugs. Da es auf Bytecode-Ebene funktioniert, kann es Dinge überprüfen, die auf Quellenebene unmöglich sind. Während es seinen fairen Anteil an Junks ausspuckt, hat es viele tatsächliche und wichtige Fehler in unserem Code gefunden.

Alex Miller
quelle
4

Und 10 Jahre später ... 2018 benutze ich alle Checkstyle, PMD und FindBugs.

Beginnen Sie mit FindBugs . Vielleicht später PMD und Checkstyle hinzufügen.

Setzen Sie niemals blind die Standardregeln durch !

Schritte:

  • Führen Sie ein Tool mit Standardregeln für ein Projekt aus, das viel Code enthält
  • Passen Sie die Regeln an dieses Projekt an, kommentieren Sie nutzlose Regeln mit einigen Notizen aus
  • Konzentrieren Sie sich auf die Regeln für niedrig hängende Früchte (NPE, Logger-Checks, nicht geschlossene Ressourcen-Checks, ...).
  • Führen Sie einige Korrekturen für Regeln durch, die Sie für sinnvoll halten (nacheinander!).
  • Tun Sie dies für jedes Werkzeug, aber nicht alle auf einmal!
  • Wiederholen Sie diesen Vorgang

Im Idealfall kann jedes Projekt separate Regeln haben. Ich mag es, die Regeln über den Build (über Maven-Plugins) auszuführen und bei Regelfehlern fehlzuschlagen, sobald ich weiß, dass ein Projekt alle von mir definierten Regeln erfüllt. Dies zwingt Entwickler zum Handeln, da die Berichterstellung nicht ausreicht . Ab diesem Zeitpunkt ist Ihr Projekt ziemlich kugelsicher und Sie können später sogar weitere Regeln hinzufügen und / oder benutzerdefinierte Regeln schreiben.

Christophe Roussy
quelle
Zu Ihrer Information , SpotBugs ist der "spirituelle Nachfolger von FindBugs" , und die SpotBugs-Dokumentation ist ziemlich gut. Soweit ich weiß, wurde FindBugs seit Jahren nicht mehr aktualisiert.
Skomisa
Ich habe noch nie von SpotBugs gehört, wahrscheinlich weil FindBugs + fbcontrib lange genug war. Gut zu wissen, dass es einen Ersatz gibt
Christophe Roussy
Es gibt einige Diskussionen darüber hier: news.ycombinator.com/item?id=12885549
Christophe Roussy
Es ist auch erwähnenswert, dass Werkzeuge in der Regel eine konfigurierbare Empfindlichkeit aufweisen. Wenn Sie beispielsweise mit FindBugs / SpotBugs beginnen, müssen Sie möglicherweise einen hohen Schwellenwert auswählen, um nur die schwerwiegendsten Fehler zu erkennen, und dann den Schwellenwert senken, wenn Sie Probleme beheben.
ThrawnCA
@ThrawnCA ja, aber auch mit Sensibilität: Bei einem großen Projekt werden zu viele Fehler gefunden, um in angemessener Zeit behoben zu werden. Stattdessen füge ich stattdessen jeweils eine Regel hinzu, beginnend mit den niedrigsten hängenden Früchten wie der potenziellen NP-Erkennung, und gehe dann zu Regeln wie nicht geschlossenen Ressourcen über.
Christophe Roussy
3

Ein Punkt, den ich bisher nicht gesehen habe, ist, dass es Plugins für IDEs gibt, die CheckStyle-Regelsätze für Ihren Code erzwingen, während PMD-Plugins nur Verstöße melden. In einem Projekt mit mehreren Standorten über mehrere Programmierteams ist es beispielsweise wichtig, Standards aktiv durchzusetzen und nicht nur darüber zu berichten.

Beide Tools verfügen über Plugins für IntelliJ, NetBeans und Eclipse (meiner Ansicht nach deckt dies die meisten Anwendungen ab). Ich bin mit NetBeans nicht so vertraut und kann daher nur zu IntelliJ und Eclipse Stellung nehmen.

Auf jeden Fall generieren die PMD-Plugins für IntelliJ und Eclipse bei Bedarf Berichte zu PMD-Verstößen innerhalb der Projektcodebasis.

Die CheckStyle-Plugins hingegen werden Verstöße im laufenden Betrieb hervorheben und können (zumindest für IntelliJ, ich habe weniger Erfahrung mit Eclipse) so konfiguriert werden, dass einige Probleme automatisch konvertiert werden (z. B. für 'OneStatementPerLine' wird CR-LF platziert Zwischen den Anweisungen für 'NeedBraces' werden geschweifte Klammern hinzugefügt, wo sie fehlen usw.). Natürlich können nur die einfacheren Verstöße automatisch behoben werden, aber es ist immer noch eine Hilfe bei älteren Projekten oder Projekten, die sich an mehreren Standorten befinden.

"On Demand" für PMD bedeutet, dass der Entwickler sich bewusst dafür entscheiden muss, den Bericht auszuführen. Checkstyle-Verstöße werden ihnen bei ihrer Entwicklung automatisch gemeldet. Während PMD tut eine umfangreichere ruleset enthält, ist die automatische enforecement / Berichterstattung von Verletzungen in IDEs in meinem Kopf der Mühe wert aufrechtzuerhalten 2 Sätze von Regeln.

Also für alle Projekte auf ich arbeiten, verwenden wir beide Tools, Check in der IDE erzwungen, berichtet PMD in der IDE, und beide abbilden und in Builds (durch Jenkins).

GKelly
quelle
1
Es gibt auch Möglichkeiten, es in den Build zu integrieren und es bei Verstößen zum Scheitern zu bringen (zum Beispiel mit Maven). Ich habe dies für Checkstyle, PMD und FindBugs getan. Wie Sie sagten, reicht die Berichterstattung nicht aus.
Christophe Roussy
3

Schauen Sie sich das qulice-maven-Plugin an , das Checkstyle, PMD, FindBugs und einige andere statische Analysegeräte kombiniert und vorkonfiguriert. Das Schöne an dieser Kombination ist, dass Sie sie nicht in jedem Projekt einzeln konfigurieren müssen:

<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
quelle
Wie konfiguriere ich es, um einen Bericht zu erhalten (in einem verwendbaren Format)? Jetzt spuckt es nur noch auf die Konsole, auch wenn ich log4j konfiguriere. Ich sehe, dass es einen Fehlerbericht gibt, der möglicherweise damit zusammenhängt, bin mir aber nicht sicher.
Adam Arold
Wir denken das Gleiche, aber um das Problem zu beheben, muss es in meinem Code oder ähnlichem hervorgehoben werden. Zumindest hast du settings.jargeholfen.
Adam Arold
2

Ich würde den Kommentar wiederholen, dass PMD das aktuellere Produkt für die Überprüfung von Java-Stilen / Konventionen ist. In Bezug auf FindBugs verwenden viele kommerzielle Entwicklungsgruppen Coverity.

Steve Moyer
quelle
1

PMD ist das, worauf sich mehr Leute beziehen. Checkstyle war das, worauf sich die Leute vor 4 Jahren bezogen haben, aber ich glaube, dass PMD kontinuierlicher gepflegt wird und mit welchen anderen IDEs / Plugins gearbeitet wird.

anjanb
quelle
2
Richtig im Jahr 2008, aber heute hat Checkstyle viel Fahrt aufgenommen.
Barfuin
1

Ich habe gerade angefangen, Checkstyle und PMD zu verwenden. Für mich ist es einfacher, mit PMD benutzerdefinierte Regeln für Dinge zu erstellen, z. B. ob System.gc () oder Runtime.gc () vorhanden sind, solange Sie die XPath-Abfrage schreiben können, was ebenfalls überhaupt nicht schwierig ist. PMD hat mir jedoch nicht gezeigt, dass es die Funktion zum Anzeigen der Spaltennummer bietet. Also für Dinge wie Spaltengrenzen prüfen. Möglicherweise möchten Sie Checkstyle verwenden.

JP
quelle
-2

PMD ist das beste Werkzeug im Vergleich zu Checkstyles. Checkstyles sind möglicherweise nicht in der Lage, den Code zu analysieren, während PMD viele Funktionen bietet, um dies zu tun! Offcourse PMD hat keine Regeln für Javadoc, Kommentare, Einrückungen usw. veröffentlicht. Übrigens plane ich, diese Regeln umzusetzen ....... Danke

janasainik
quelle
Eine gute Sache über Checkstyle ist, dass es einige flexible Regeln wie RegexpSingleline erlaubt ...
Jigar Shah