Welche Code-Analyse-Tools verwenden Sie für Ihre Java-Projekte? [geschlossen]

Welche Code-Analyse-Tools verwenden Sie in Ihren Java-Projekten?

Ich interessiere mich für alle Arten

• Tools zur statischen Code-Analyse (FindBugs, PMD und andere)
• Tools zur Codeabdeckung (Cobertura, Emma und andere)
• alle anderen instrumentenbasierten Werkzeuge
• alles andere, wenn mir etwas fehlt

Geben Sie gegebenenfalls auch an, welche Build-Tools Sie verwenden und wie gut diese Tools in Ihre IDEs und Build-Tools integriert sind.

Wenn ein Tool nur auf eine bestimmte Weise verfügbar ist (als IDE-Plugin oder beispielsweise als Build-Tool-Plugin), sind diese Informationen ebenfalls erwähnenswert.

Für statische Analysetools verwende ich häufig CPD, PMD , FindBugs und Checkstyle .

CPD ist das PMD-Tool "Copy / Paste Detector". Ich habe PMD eine Weile verwendet, bevor ich den Link "Finding Duplicated Code" auf der PMD-Webseite bemerkte .

Ich möchte darauf hinweisen, dass diese Tools manchmal über ihre "out-of-the-box" -Regeln hinaus erweitert werden können. Und das nicht nur, weil sie Open Source sind, damit Sie sie neu schreiben können. Einige dieser Tools werden mit Anwendungen oder "Hooks" geliefert, mit denen sie erweitert werden können. Zum Beispiel wird PMD mit dem "Designer" -Tool geliefert, mit dem Sie neue Regeln erstellen können. Außerdem verfügt Checkstyle über die DescendantToken- Prüfung mit Eigenschaften, die eine umfassende Anpassung ermöglichen.

Ich integriere diese Tools in einen Ant-basierten Build . Sie können dem Link folgen, um meine kommentierte Konfiguration zu sehen.

Zusätzlich zur einfachen Integration in den Build finde ich es hilfreich, die Tools so zu konfigurieren, dass sie auf verschiedene andere Arten etwas "integriert" sind. Gleichmäßigkeit der Berichterstellung und der Unterdrückung von Warnungen. Ich möchte diese Aspekte zu dieser Diskussion hinzufügen (die wahrscheinlich auch das Tag "statische Analyse" haben sollte): Wie konfigurieren die Leute diese Tools, um eine "einheitliche" Lösung zu erstellen? (Ich habe diese Frage hier separat gestellt )

Zunächst transformiere ich für Warnberichte die Ausgabe so, dass jede Warnung das einfache Format hat:

/absolute-path/filename:line-number:column-number: warning(tool-name): message

Dies wird oft als "Emacs-Format" bezeichnet, aber selbst wenn Sie Emacs nicht verwenden, ist es ein vernünftiges Format zum Homogenisieren von Berichten. Beispielsweise:

/project/src/com/example/Foo.java:425:9: warning(Checkstyle):Missing a Javadoc comment.

Meine Transformationen des Warnformats werden von meinem Ant-Skript mit Ant- Filterketten durchgeführt .

Die zweite "Integration", die ich mache, dient der Unterdrückung von Warnungen. Standardmäßig unterstützt jedes Tool Kommentare oder Anmerkungen (oder beides), die Sie in Ihren Code einfügen können, um eine Warnung auszuschalten, die Sie ignorieren möchten. Diese verschiedenen Anforderungen zur Unterdrückung von Warnungen sehen jedoch nicht einheitlich aus, was etwas albern erscheint. Wenn Sie eine Warnung unterdrücken, unterdrücken Sie eine Warnung. Warum also nicht immer " SuppressWarning?"

Beispielsweise unterdrückt die Standardkonfiguration von PMD die Generierung von Warnungen in Codezeilen mit der Zeichenfolge " NOPMD" in einem Kommentar. Außerdem unterstützt PMD die @SuppressWarningsAnnotation von Java . Ich konfiguriere PMD so, dass Kommentare verwendet werden, die " SuppressWarning(PMD." enthalten, anstatt NOPMDdass PMD-Unterdrückungen gleich aussehen. Ich fülle die bestimmte Regel aus, gegen die bei Verwendung der Unterdrückung des Kommentarstils verstoßen wird:

// SuppressWarnings(PMD.PreserveStackTrace) justification: (false positive) exceptions are chained

Nur der SuppressWarnings(PMD.Teil " " ist für einen Kommentar von Bedeutung, stimmt jedoch mit der Unterstützung von PMD für die @SuppressWarningAnmerkung überein, mit der einzelne Regelverletzungen namentlich erkannt werden:

@SuppressWarnings("PMD.CompareObjectsWithEquals") // justification: identity comparision intended

In ähnlicher Weise unterdrückt Checkstyle die Generierung von Warnungen zwischen Kommentarpaaren (es wird keine Unterstützung für Anmerkungen bereitgestellt). Standardmäßig Kommentare Check aus und enthalten die Saiten zu drehen CHECKSTYLE:OFFund CHECKSTYLE:ONsind. Durch Ändern dieser Konfiguration (mit Checkstyles "SuppressionCommentFilter") zur Verwendung der Zeichenfolgen " BEGIN SuppressWarnings(CheckStyle." und " END SuppressWarnings(CheckStyle." sehen die Steuerelemente eher wie PMD aus:

// BEGIN SuppressWarnings(Checkstyle.HiddenField) justification: "Effective Java," 2nd ed., Bloch, Item 2
// END SuppressWarnings(Checkstyle.HiddenField)

Mit Check Kommentaren, die bestimmte Kontrollverletzung ( HiddenField) ist von Bedeutung , da jede Überprüfung sein eigenes „hat BEGIN/END“ Kommentar Paar.

FindBugs unterstützt auch die Unterdrückung der Warnungsgenerierung mit einer @SuppressWarningsAnmerkung, sodass keine weitere Konfiguration erforderlich ist, um ein gewisses Maß an Einheitlichkeit mit anderen Tools zu erreichen. Leider muss Findbugs eine benutzerdefinierte @SuppressWarningsAnnotation unterstützen, da die integrierte Java- @SuppressWarningsAnnotation eine SOURCEAufbewahrungsrichtlinie enthält, die nicht stark genug ist, um die Annotation in der Klassendatei beizubehalten, in der FindBugs sie benötigt. Ich qualifiziere die Unterdrückung von FindBugs-Warnungen vollständig, um Konflikte mit der @SuppressWarningsAnnotation von Java zu vermeiden :

@edu.umd.cs.findbugs.annotations.SuppressWarnings("UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR")

Diese Techniken lassen die Dinge zwischen den Werkzeugen einigermaßen konsistent aussehen. Beachten Sie, dass jede Warnungsunterdrückung die Zeichenfolge " SuppressWarnings" enthält, was es einfach macht, eine einfache Suche durchzuführen, um alle Instanzen für alle Tools über eine gesamte Codebasis zu finden.

Ich benutze eine Kombination aus Cobertura, Checkstyle, (Ecl) Emma und Findbugs.

EclEmma ist ein fantastisches Eclipse-Plugin, das die Codeabdeckung durch Färben der Java-Quelle im Editor anzeigt ( Screenshot) ) - die Abdeckung wird durch Ausführen eines JUnit-Tests generiert. Dies ist sehr nützlich, wenn Sie herausfinden möchten, welche Zeilen in einer bestimmten Klasse abgedeckt sind, oder wenn Sie nur sehen möchten, welche Zeilen von einem einzelnen Test abgedeckt werden. Dies ist viel benutzerfreundlicher und nützlicher als das Erstellen eines Berichts und das anschließende Durchsuchen des Berichts, um festzustellen, welche Klassen eine geringe Abdeckung aufweisen.

Die Plugins Stylestyle und Findbugs Eclipse sind ebenfalls nützlich. Sie generieren während der Eingabe Warnungen im Editor.

Maven2 verfügt über Berichts-Plugins, die mit den oben genannten Tools zusammenarbeiten, um Berichte zur Erstellungszeit zu erstellen. Wir verwenden dies, um allgemeine Projektberichte zu erhalten, die nützlicher sind, wenn Sie aggregierte Zahlen wünschen. Diese werden von unseren CI-Builds generiert, die mit Continuum ausgeführt werden .

Alle folgenden Funktionen verwenden und integrieren wir einfach in unsere Maven 2.x-Builds und in Eclipse / RAD 7:

• Testen - JUnit / TestNG
• Codeanalyse - FindBugs, PMD
• Codeabdeckung - Klee

Darüber hinaus haben wir in unseren Maven-Builds:

• JDepend
• Tag Checker (TODO, FIXME usw.)

Wenn Sie Maven 2.x verwenden, hat CodeHaus außerdem eine Sammlung praktischer Maven-Plugins in seinem Mojo-Projekt .

Hinweis: Clover ist sofort in den Bamboo CI-Server integriert (da beide Atlassian-Produkte sind). Es gibt auch Bamboo-Plugins für FindBugs, PMD und CheckStyle, aber wie bereits erwähnt, hat der kostenlose Hudson CI-Server diese auch.

Ich verwende die in IntelliJ IDEA integrierte statische Analyse. Perfekte Integration.

Ich verwende die in Intellij IDEA integrierte Codeabdeckung (basierend auf EMMA). Wieder perfekte Integration.

Diese integrierte Lösung ist zuverlässig, leistungsstark und benutzerfreundlich im Vergleich zum Zusammensetzen von Tools verschiedener Anbieter.

Checkstyle ist ein anderer, den ich bei einer früheren Firma verwendet habe ... er dient hauptsächlich der Stilprüfung, kann aber auch statische Analysen durchführen. Auch Clover für die Codeabdeckung, obwohl Sie sich bewusst sind, dass es kein kostenloses Tool ist.

Wir verwenden FindBugs und Checkstyle sowie Clover für die Codeabdeckung.

Ich denke, es ist wichtig, eine statische Analyse zu haben, die Ihre Entwicklung unterstützt. Leider ist es immer noch nicht weit verbreitet, dass diese Tools wichtig sind.

Wir verwenden FindBugs und JDepend, die in Ant integriert sind. Wir verwenden JUnit, aber kein Coverage-Tool.

Ich verwende es nicht integriert in Rational Application Developer (die IDE, mit der ich J2EE-Anwendungen entwickle), weil mir gefällt, wie gut es aussieht, wenn Sie Javac in der Windows-Konsole ausführen. : P.

Ich hatte viel Glück mit Cobertura. Es ist ein Tool zur Codeabdeckung, das als Teil Ihres normalen Builds über Ihr Ant-Skript ausgeführt und in Hudson integriert werden kann.

Unser Team verwendet PMD und Cobertura, eigentlich sind unsere Projekte Maven-Projekte und es ist sehr einfach, Plug-Ins für die Code-Analyse einzuschließen. Die eigentliche Frage wäre für ein bestimmtes Projekt, welche Analyse Sie verwenden müssen. Meiner Meinung nach können Sie nicht für jedes Projekt dieselben Plugins verwenden.

In unserem Projekt verwenden wir Sonar vor Checkstyle, PMD. Zusammen mit dem CI (Bamboo, Hudson) erhalten wir auch eine schöne Geschichte unserer Quellqualität und unserer Regie. Ich mag Sonar, weil Sie ein zentrales Tool im CI-Stack sind, das dies für Sie erledigt, und Sie die Regeln für jedes Projekt einfach anpassen können.

Struktur 101 ist gut in der Codeanalyse und beim Auffinden der zyklischen Paketabhängigkeiten.

Ich suche nach vielen Antworten, um mehr über neue Tools zu erfahren und dieses Wissen in einer Frage / einem Thread zu konsolidieren. Daher bezweifle ich, dass es eine echte Antwort auf diese Frage geben wird.

Meine Antwort auf meine eigene Frage lautet:

• Findbugs, um nach häufigen Fehlern zu suchen, die schlecht / codiert sind - werden von Maven ausgeführt und lassen sich auch problemlos in Eclipse integrieren
• Cobertura für unsere Berichterstattungsberichte - laufen von Maven

Hudson hat auch ein Task-Scanner-Plugin, das eine Anzahl Ihrer TODO- und FIXMEs anzeigt und anzeigt, wo sie sich in den Quelldateien befinden.

Alle sind in unserem Fall in Maven 1.x integriert und in Hudson eingebunden, das unsere Builds für Check-in sowie zusätzliche Dinge jeden Abend und wöchentlich ausführt. Der Hudson-Trend zeigt grafisch unsere JUnit-Tests, Abdeckung, Findbugs sowie offene Aufgaben. Es gibt auch ein Hudson-Plugin, das unsere Kompilierungswarnungen meldet und grafisch darstellt. Wir haben auch mehrere Leistungstests mit eigenen Diagrammen der Leistung und der Speichernutzung im Zeitverlauf unter Verwendung des Hudson-Plots-Plugins.