Checkstyle vs. PMD

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.

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.

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

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/

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

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

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.

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

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.

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

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.

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.

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

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>

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.

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.

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.

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