webentwicklung-frage-antwort-db.com.de

Checkstyle vs. PMD

Wir führen statische Analyse-Tools in das Build-System für unser Java) Produkt ein. Wir verwenden Maven2, also Checkstyle und PMD Die Integration ist kostenlos, es scheint jedoch eine große Überschneidung in der Funktionalität zwischen diesen beiden Tools zu geben, was die Durchsetzung grundlegender Stilregeln angeht.

Gibt es einen Vorteil, wenn beide genutzt werden? Ich möchte nicht zwei Werkzeuge warten, wenn eines funktioniert. Wenn wir uns für einen entscheiden, welchen 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 gegenüber CheckStyle bevorzugt 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 auf PMD abzielen. Wir werden auch FindBugs und eventuell Macker einbeziehen, um die architektonischen Regeln durchzusetzen.

83
John Stauffer

Sie sollten unbedingt FindBugs verwenden. Meiner Erfahrung nach ist die Falsch-Positiv-Quote sehr niedrig, und selbst die am wenigsten kritischen Warnungen, die gemeldet werden, sollten in gewissem Maße berücksichtigt werden.

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 die Ausgabe ist im Allgemeinen relevanter und nützlicher.

66
Chris Vest

Beide Software sind nützlich. Checkstyle hilft Ihnen beim Programmieren, indem es Ihren Codierungsstil prüft, d. H. Klammern, Namen usw. Einfache Dinge, aber sehr zahlreich!

PMD hilft Ihnen, indem es kompliziertere Regeln wie beim Entwerfen Ihrer Klassen oder spezielle Probleme wie die korrekte Implementierung der Klonfunktion überprüft. PMD überprüft einfach Ihr Programmierstil

Beide Software leidet jedoch unter ähnlichen Regeln, die manchmal schlecht erklärt werden. Bei einer schlechten Konfiguration können Sie zweimal oder zweimal das Gegenteil überprüfen, z. B. "Unnützige Konstruktoren entfernen" und "Immer einen Konstruktor".

36
temptfate

Wenn wir uns für einen entscheiden, welchen sollten wir verwenden und warum?

Diese Tools stehen nicht im Wettbewerb, sondern ergänzen sich und sollten gleichzeitig verwendet werden.

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

Checkstyle Beispiele:

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

während PMD Sie an schlechte Praktiken erinnert:

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

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

22
Lucas

Wir verwenden beide:

  • Checkstyle, um sicherzustellen, dass jeder im Team den Code auf ähnliche Weise schreibt
  • PMD, um problematische Codebereiche und nächste Refactoring-Ziele zu finden
13
Ilya Kochetov

Wenn Ihr primärer Verwendungszweck 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.

Check out http://code.google.com/javadevtools/download-codepro.html

7
Naveen

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

Das heißt, Findbugs hat 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 sollten ernst genommen werden. Mit Checkstyle und PMD sind die Regeln allgemeiner und stilbezogener. Sie sollten daher nur mit benutzerdefinierten Konfigurationsdateien verwendet werden, um dem Team eine Lawine irrelevanten Feedbacks zu ersparen ("Tab char on line 5", "Tab char on line 6", "Tab char on line 7" ... Sie erhalten das Bild). Sie bieten auch leistungsstarke Tools zum Schreiben Ihrer eigenen erweiterten Regeln, z. die Checkstyle DescendentToken Regel.

Wenn Sie alle drei (insbesondere mit einem Tool wie Sonar) verwenden, sollten Sie alle separat konfigurieren (es dauert mindestens ein paar Tage, bis alle Regeln abgedeckt sind) und dabei darauf achten, dass keine Duplikate auftreten (alle drei Tools stellen fest, dass hashCode () verwendet wurde) überschrieben und gleich () nicht zum Beispiel).

Zusammenfassend kann gesagt werden, dass, wenn Sie die statische Code-Analyse für wertvoll halten, das Zurückweisen eines der drei Werte keinen Sinn ergibt. Um jedoch alle drei Werte zu verwenden, müssen Sie Zeit investieren, um sie so zu konfigurieren, dass Sie brauchbares Feedback erhalten.

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

Dies weist auch darauf hin, dass alle 3 Werkzeuge ein Existenzrecht haben ...

6
DaveFar

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 findet Codeduplizierung ü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 , die sich mit vielen Tools befasst, die für die Java/Java EE-Entwicklung hilfreich sind

5
user68838

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

Wenn es für Sie wichtige Dinge gibt, die Checkstyle standardmäßig erledigt, ohne dass PMD dies tut, können Sie eine minimale Checkstyle-Konfiguration in Betracht ziehen, bei der nur diese Überprüfungen vorgenommen werden. Stellen Sie dann eine Richtlinie ein, mit der die Checkstyle-Konfiguration nicht erweitert werden kann. Entfernen Sie einfach die Überprüfungen, während Sie ähnliche Funktionen beispielsweise mit benutzerdefinierten PMD-Regeln implementieren.

Bedenken Sie auch, dass Sie PMD/Checkstyle anstelle von PMD/Macker implementieren können, wenn Sie sich dafür entscheiden, dass die Checkstyle-Funktion "Importkontrolle" das abdeckt, was Sie von Macker wollten. In beiden Fällen handelt es sich um zwei Tools, aber mit Checkstyle erhalten Sie die Dinge, die PMD nicht sofort "kostenlos" erledigt.

4
Greg Mattes

Ich finde, Checkstyle und PMD eignen sich am besten, um Stilprobleme und einfache offensichtliche Programmierfehler durchzusetzen. Obwohl ich festgestellt habe, dass ich Eclipse und alle Warnungen, die es für diesen Zweck bietet, gerne benutze. Wir erzwingen Dinge, indem wir gemeinsame Einstellungen verwenden und sie als tatsächliche Fehler markieren. Auf diese Weise werden sie niemals eingecheckt.

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

4
Alex Miller

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. Beispielsweise ist es in einem Projekt mit mehreren Standorten und mehreren Programmierteams wichtig, Standards aktiv durchzusetzen, anstatt nur darüber zu berichten.

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

Wie auch immer, die PMD-Plugins für IntelliJ und Eclipse generieren Berichte auf Anfrage über PMD-Verstöße innerhalb der Projekt-Codebasis.

Die CheckStyle-Plugins heben dagegen Verstöße im Handumdrehen hervor 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'), CR-LF platzieren zwischen Anweisungen werden für 'NeedBraces' 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. Während Checkstyle-Verstöße automatisch gemeldet werden, sobald sie auftreten. Während PMD does einen umfangreicheren Regelsatz enthält, ist es meiner Meinung nach die Mühe wert, 2 Regelsätze zu verwalten, um Verstöße in IDEs automatisch durchzusetzen/zu melden.

Für alle Projekte, an denen ich arbeite, verwenden wir beide Tools, Checkstyle in der IDE erzwungen, PMD in der IDE gemeldet und beide in Builds gemeldet und gemessen (über Jenkins).

3
GKelly

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

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

Erzwinge niemals blind die Standardregeln!

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 und kommentieren Sie unnötige Regeln mit einigen Anmerkungen
  • konzentration 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 sich für Sie lohnen (einzeln!).
  • tun Sie dies für jedes Werkzeug, aber nicht auf einmal!
  • wiederholen Sie diesen Vorgang

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

3

Schauen Sie sich qulice-maven-plugin an, das Checkstyle, PMD, FindBugs und einige andere statische Analysatoren 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>
2
yegor256

Ich würde die Bemerkung wiederholen, dass PMD das aktuellere Produkt für Java Stil-/Konventionsprüfungen ist. In Bezug auf FindBugs verwenden viele kommerzielle Entwicklungsgruppen Coverity.

1
Steve Moyer

Ich habe gerade angefangen, Checkstyle und PMD zu benutzen. Für mich ist es mit PMD einfacher, benutzerdefinierte Regeln für Dinge wie System.gc (), Runtime.gc () zu erstellen, sofern Sie die XPath-Abfrage schreiben können, die auch überhaupt nicht schwierig ist. PMD hat mir jedoch nicht gezeigt, dass es die Funktion zum Anzeigen der Spaltennummer hat. Also für Dinge wie Spaltengrenzen überprüfen. Vielleicht möchten Sie Checkstyle verwenden.

1
J.P.

PMD ist das, worauf sich mehr Leute beziehen. Checkstyle war das, worauf sich die Leute vor 4 Jahren bezogen, aber ich glaube, PMD wird immer weiter gepflegt und mit welchen anderen IDEs/Plugins man arbeiten möchte.

0
anjanb