Einführung in CheckStyle

1. Übersicht

Checkstyle ist ein Open Source-Tool, das Code anhand eines konfigurierbaren Regelwerks überprüft.

In diesem Tutorial erfahren Sie, wie Sie Checkstyle über Maven und mithilfe von IDE-Plugins in ein Java-Projekt integrieren.

Die in den folgenden Abschnitten genannten Plugins sind nicht voneinander abhängig und können einzeln in unsere Build- oder IDEs integriert werden. Zum Beispiel wird das Maven-Plugin in unserer pom.xml nicht benötigt , um die Validierungen in unserer Eclipse-IDE auszuführen.

2. Checkstyle Maven Plugin

2.1. Maven-Konfiguration

Um Checkstyle zu einem Projekt hinzuzufügen, müssen wir das Plugin im Berichtsabschnitt einer pom.xml hinzufügen :

   org.apache.maven.plugins maven-checkstyle-plugin 3.0.0  checkstyle.xml    

Dieses Plugin enthält zwei vordefinierte Prüfungen, eine Prüfung im Sun-Stil und eine Prüfung im Google-Stil . Die Standardprüfung für ein Projekt lautet sun_checks.xml.

Um unsere benutzerdefinierte Konfiguration zu verwenden, können wir unsere Konfigurationsdatei wie im obigen Beispiel gezeigt angeben. Mit dieser Konfiguration liest das Plugin nun unsere benutzerdefinierte Konfiguration anstelle der bereitgestellten Standardkonfiguration.

Die neueste Version des Plugins finden Sie auf Maven Central.

2.2. Berichterstellung

Nachdem unser Maven-Plugin konfiguriert ist, können wir einen Bericht für unseren Code erstellen, indem wir den Befehl mvn site ausführen . Nach Abschluss des Builds ist der Bericht im Ordner target / site unter dem Namen checkstyle.html verfügbar .

Ein Checkstyle-Bericht besteht aus drei Hauptteilen:

Dateien: Dieser Abschnitt des Berichts enthält die Liste der Dateien, in denen die Verstöße aufgetreten sind . Es zeigt uns auch die Anzahl der Verstöße gegen ihren Schweregrad. So sieht der Dateibereich des Berichts aus:

Regeln: Dieser Teil des Berichts gibt uns einen Überblick über die Regeln, die zur Überprüfung auf Verstöße verwendet wurden . Es zeigt die Kategorie der Regeln, die Anzahl der Verstöße und die Schwere dieser Verstöße. Hier ist ein Beispiel des Berichts, der den Abschnitt mit den Regeln zeigt:

Details: Schließlich enthält der Detailabschnitt des Berichts die Details der aufgetretenen Verstöße . Die angegebenen Details befinden sich auf Zeilennummernebene. Hier ist ein Abschnitt mit Beispieldetails des Berichts:

2.3. Integration erstellen

Wenn der Codierungsstil streng überprüft werden muss, können wir das Plugin so konfigurieren, dass der Build fehlschlägt, wenn der Code nicht den Standards entspricht.

Dazu fügen wir unserer Plugin-Definition ein Ausführungsziel hinzu:

 org.apache.maven.plugins maven-checkstyle-plugin ${checkstyle-maven-plugin.version}  checkstyle.xml     check    

Das Attribut configLocation definiert, auf welche Konfigurationsdatei für die Validierungen verwiesen werden soll.

In unserem Fall lautet die Konfigurationsdatei checkstyle.xml. Das Ziel Prüfung in dem Ausführungsabschnitt erwähnte , fragt das Plugin in der Verifizierungsphase des Builds und Kräfte einen Build - Fehler , wenn eine Verletzung der Codierungsstandards laufen auftritt.

Wenn wir jetzt den Befehl mvn clean install ausführen , werden die Dateien auf Verstöße überprüft und der Build schlägt fehl, wenn Verstöße festgestellt werden.

Wir können auch nur das Prüfziel des Plugins mit mvn checkstyle: check ausführen , ohne das Ausführungsziel zu konfigurieren. Das Ausführen dieses Schritts führt auch zu einem Build-Fehler, wenn Validierungsfehler vorliegen.

3. Eclipse Plugin

3.1. Konfigurationen

Genau wie bei der Maven-Integration können wir mit Eclipse unsere benutzerdefinierte Konfiguration verwenden.

Um unsere Konfiguration zu importieren, gehen Sie zu Fenster -> Einstellungen -> Checkstyle. Am globalen prüfen Konfigurationen Abschnitt, klicken Sie auf Neu.

Dies öffnet einen Dialog, der uns Optionen zur Angabe unserer benutzerdefinierten Konfigurationsdatei bietet.

3.2. Durchsuchen von Berichten

Nachdem unser Plugin konfiguriert ist, können wir damit unseren Code analysieren.

Um den Codierungsstil für ein Projekt zu überprüfen, klicken Sie im Eclipse- Projektexplorer mit der rechten Maustaste auf das Projekt und wählen Sie CheckStyle -> Code mit Checkstyle prüfen.

Das Plugin gibt uns Feedback zu unserem Java-Code im Eclipse-Texteditor. Außerdem wird der Verstoßbericht für das Projekt generiert, der als Ansicht in Eclipse verfügbar ist.

Um den Verstoßbericht anzuzeigen, gehen Sie zu Fenster -> Ansicht anzeigen -> Andere und suchen Sie nach Checkstyle. Optionen für Verstöße und Verstoßdiagramm sollten angezeigt werden.

Wenn Sie eine der beiden Optionen auswählen, werden die nach Typ gruppierten Verstöße dargestellt. Hier ist das Verstoßdiagramm für ein Beispielprojekt:

Wenn Sie auf einen Abschnitt des Kreisdiagramms klicken, gelangen Sie zur Liste der tatsächlichen Verstöße im Code.

Alternativ können wir die Problemansicht der Eclipse-IDE öffnen und die vom Plugin gemeldeten Probleme überprüfen.

Hier ist ein Beispiel für eine Problemansicht der Eclipse-IDE:

Wenn Sie auf eine der Warnungen klicken, gelangen Sie zu dem Code, in dem der Verstoß aufgetreten ist.

4. IntelliJ IDEA Plugin

4.1. Aufbau

Wie Eclipse können wir mit IntelliJ IDEA auch unsere eigenen benutzerdefinierten Konfigurationen für ein Projekt verwenden.

Öffnen Sie in der IDE Einstellungen und suchen Sie nach Checkstyle. Es wird ein Fenster angezeigt, in dem Sie unsere Schecks auswählen können. Klicken Sie auf die Schaltfläche + und ein Fenster wird geöffnet, in dem Sie den Speicherort der zu verwendenden Datei angeben können.

Nun wählen wir eine Konfigurations-XML-Datei aus und klicken auf Weiter. Dies öffnet das vorherige Fenster und zeigt unsere neu hinzugefügte benutzerdefinierte Konfigurationsoption. Wir wählen die neue Konfiguration aus und klicken auf OK, um sie in unserem Projekt zu verwenden.

4.2. Durchsuchen von Berichten

Nachdem unser Plugin konfiguriert ist, können Sie es verwenden, um nach Verstößen zu suchen. Um nach Verstößen gegen ein bestimmtes Projekt zu suchen , gehen Sie zu Analysieren -> Code überprüfen.

Die Inspektionsergebnisse geben uns einen Überblick über die Verstöße im Abschnitt Checkstyle. Hier ist ein Beispielbericht:

Wenn Sie auf die Verstöße klicken, gelangen Sie zu den genauen Zeilen in der Datei, in der die Verstöße aufgetreten sind.

5. Benutzerdefinierte Checkstyle-Konfiguration

Im Abschnitt zur Erstellung von Maven-Berichten (Abschnitt 2.2) haben wir eine benutzerdefinierte Konfigurationsdatei verwendet, um unsere eigenen Codierungsstandardprüfungen durchzuführen.

Wir haben die Möglichkeit, eine eigene benutzerdefinierte Konfigurations-XML-Datei zu erstellen, wenn wir die verpackten Google- oder Sun-Prüfungen nicht verwenden möchten.

Hier ist die benutzerdefinierte Konfigurationsdatei, die für die obigen Überprüfungen verwendet wird:

5.1. DOCTYPE Definition

Die erste Zeile der DOCTYPE-Definition ist ein wichtiger Teil der Datei und gibt an, von wo die DTD heruntergeladen werden soll, damit die Konfigurationen vom System verstanden werden können.

Wenn wir diese Definition nicht in unsere Konfigurationsdatei aufnehmen, ist sie keine gültige Konfigurationsdatei.

5.2. Module

Eine Konfigurationsdatei besteht hauptsächlich aus Modulen. Ein Modul hat einen Attributnamen , das repräsentiert , was das Modul tut. Der Wert des Name Attribut entspricht eine Klasse im Code des Plugin , das ausgeführt wird , wenn das Plugin ausgeführt wird.

Erfahren Sie mehr über die verschiedenen Module in der obigen Konfiguration.

5.3. Moduldetails

  • Checker: Module sind in einem Baum strukturiert, in dem sich das Checker-Modul im Stammverzeichnis befindet. Dieses Modul definiert die Eigenschaften, die von allen anderen Modulen der Konfiguration geerbt werden.
  • TreeWalker: Dieses Modul überprüft die einzelnen Java-Quelldateien und definiert Eigenschaften, die zum Überprüfen solcher Dateien gelten.
  • AvoidStarImport: Dieses Modul setzt einen Standard für die Nichtverwendung von Star-Importen in unserem Java-Code. Es hat auch eine Eigenschaft, die das Plugin auffordert, den Schweregrad solcher Probleme als Warnung zu melden. Wenn solche Verstöße im Code gefunden werden, wird eine Warnung gegen sie angezeigt.

Um mehr über benutzerdefinierte Konfigurationen zu erfahren, folgen Sie diesem Link.

6. Berichtsanalyse für das Spring-Rest-Projekt

In diesem Abschnitt werden wir eine Analyse von Checkstyle anhand der in Abschnitt 5 erstellten benutzerdefinierten Konfiguration des auf GitHub verfügbaren Spring-Rest-Projekts als Beispiel beleuchten.

6.1. Erstellung von Verstößen

Wir haben die Konfiguration in die Eclipse-IDE importiert. Hier ist der Verstoßbericht, der für das Projekt generiert wird:

Die hier gemeldeten Warnungen besagen, dass Wildcard-Importe im Code vermieden werden sollten. Wir haben zwei Dateien, die diesem Standard nicht entsprechen. Wenn wir auf die Warnung klicken, gelangen wir zu der Java-Datei, die den Verstoß aufweist.

In der Datei HeavyResourceController.java wird die gemeldete Warnung folgendermaßen angezeigt :

6.2. Konfliktlösung

Die Verwendung von Star-Importen ist im Allgemeinen keine gute Vorgehensweise, da dies zu Konflikten führen kann, wenn zwei oder mehr Pakete dieselbe Klasse enthalten.

Betrachten Sie als Beispiel die Klassenliste , die in den Paketen java.util und java.awt verfügbar ist . Wenn wir beide Importe von java.util . * Und java.awt. * Verwenden, kann unser Compiler den Code nicht kompilieren, da List in beiden Paketen verfügbar ist.

Um das oben erwähnte Problem zu beheben, organisieren wir die Importe in beiden Dateien und speichern sie. Wenn wir das Plugin jetzt erneut ausführen, sehen wir keine Verstöße und unser Code folgt jetzt den in unserer benutzerdefinierten Konfiguration festgelegten Standards.

7. Fazit

In diesem Artikel haben wir die Grundlagen für die Integration von Checkstyle in unser Java-Projekt behandelt.

Wir haben gelernt, dass es sich um ein einfaches, aber leistungsstarkes Tool handelt, mit dem sichergestellt wird, dass Entwickler die von der Organisation festgelegten Codierungsstandards einhalten.

Der Beispielcode, den wir für die statische Analyse verwendet haben, ist auf GitHub verfügbar.