1. 概要

Checkstyleは、構成可能な一連のルールに対してコードをチェックするオープンソースツールです。

このチュートリアルでは、Mavenを介してIDEプラグインを使用してCheckstyleをJavaプロジェクトに統合する方法を見ていきます。

以下のセクションで説明するプラグインは相互に依存しておらず、ビルドまたはIDEに個別に統合できます。 たとえば、EclipseIDEで検証を実行するためにpom.xmlにMavenプラグインは必要ありません。

2. CheckstyleMavenプラグイン

2.1. Maven構成

プロジェクトにCheckstyleを追加するには、pom.xmlのレポートセクションにプラグインを追加する必要があります。

<reporting>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-checkstyle-plugin</artifactId>
            <version>3.0.0</version>
            <configuration>
                <configLocation>checkstyle.xml</configLocation>
            </configuration>
        </plugin>
    </plugins>
</reporting>

このプラグインには、SunスタイルのチェックとGoogleスタイルのチェックの2つの事前定義されたチェックが付属しています。 プロジェクトのデフォルトのチェックはsun_checks.xml。です。

カスタム構成を使用するには、上記のサンプルに示すように構成ファイルを指定できます。 この構成を使用すると、プラグインは、提供されているデフォルトの構成ではなく、カスタム構成を読み取るようになります。

プラグインの最新バージョンは、 MavenCentralにあります。

2.2. レポートの生成

Mavenプラグインが構成されたので、 mvnsiteコマンドを実行してコードのレポートを生成できます。 ビルドが完了すると、レポートはcheckstyle.htmlという名前でtarget/siteフォルダーに表示されます。

Checkstyleレポートには3つの主要な部分があります。

ファイル:レポートのこのセクションには、違反が発生したファイルのリストが表示されます。 また、重大度レベルに対する違反の数も表示されます。 レポートのファイルセクションは次のようになります。

ルール:レポートのこの部分は、違反のチェックに使用されたルールの概要を提供します。 ルールのカテゴリ、違反の数、およびそれらの違反の重大度が表示されます。 ルールセクションを示すレポートのサンプルを次に示します。

詳細:最後に、レポートの詳細セクションには、発生した違反の詳細が表示されます。 提供される詳細は、行番号レベルです。 レポートの詳細セクションの例は次のとおりです。

2.3. ビルド統合

コーディングスタイルを厳密にチェックする必要がある場合は、コードが標準に準拠していない場合にビルドが失敗するようにプラグインを構成できます。

これを行うには、プラグイン定義に実行目標を追加します。

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-checkstyle-plugin</artifactId>
    <version>${checkstyle-maven-plugin.version}</version>
    <configuration>
        <configLocation>checkstyle.xml</configLocation>
    </configuration>
    <executions>
        <execution>
            <goals>
                <goal>check</goal>
            </goals>
        </execution>
    </executions>
</plugin>

configLocation 属性は、検証のために参照する構成ファイルを定義します。

この場合、構成ファイルは checkstyle.xmlです。実行セクションに記載されている目標チェックは、プラグインにビルドの検証フェーズで実行するように要求し、次の場合にビルドの失敗を強制します。コーディング標準の違反が発生します。

ここで、 mvn clean install コマンドを実行すると、ファイルの違反がスキャンされ、違反が見つかった場合はビルドが失敗します。

また、実行目標を設定せずに、 mvn checkstyle:check、を使用して、プラグインのcheck目標のみを実行できます。 この手順を実行すると、検証エラーがある場合にもビルドが失敗します。

3. Eclipseプラグイン

3.1. 構成

Maven統合と同様に、Eclipseではカスタム構成を使用できます。

構成をインポートするには、ウィンドウ->設定->Checkstyleに移動します。グローバルチェック構成セクションで、新規。をクリックします。

これにより、カスタム構成ファイルを指定するためのオプションを提供するダイアログが開きます。

3.2. レポートの閲覧

プラグインが構成されたので、それを使用してコードを分析できます。

プロジェクトのコーディングスタイルを確認するには、 Eclipse Project Explorer でプロジェクトを右クリックし、 CheckStyle-> Check CodewithCheckstyleを選択します。

プラグインは、Eclipse内のJavaコードに関するフィードバックをテキストエディターで提供します。また、Eclipseでビューとして使用できるプロジェクトの違反レポートを生成します。

違反レポートを表示するには、ウィンドウ->ビューの表示->その他に移動し、Checkstyleを検索します。 違反および違反チャートのオプションが表示されます。

いずれかのオプションを選択すると、タイプ別にグループ化された違反が表示されます。 サンプルプロジェクトの違反円グラフは次のとおりです。

円グラフのセクションをクリックすると、コード内の実際の違反のリストが表示されます。

または、EclipseIDEのProblem ビューを開いて、プラグインによって報告された問題を確認することもできます。

EclipseIDEの問題ビューの例を次に示します。

警告のいずれかをクリックすると、違反が発生したコードに移動します。

4. IntelliJIDEAプラグイン

4.1. 構成

Eclipseと同様に、IntelliJ IDEAを使用すると、プロジェクトで独自のカスタム構成を使用することもできます。

IDEで[設定]を開き、Checkstyleを検索します。 チェックを選択するオプションがあるウィンドウが表示されます。 + ボタンをクリックするとウィンドウが開き、使用するファイルの場所を指定できます。

次に、構成XMLファイルを選択し、[次へ]をクリックします。 これにより、前のウィンドウが開き、新しく追加されたカスタム構成オプションが表示されます。 新しい構成を選択し、[OK]をクリックしてプロジェクトでの使用を開始します。

4.2. レポートの閲覧

プラグインが構成されたので、それを使用して違反をチェックしましょう。 特定のプロジェクトの違反をチェックするには、分析->コードの検査に移動します。

検査結果は、Checkstyleセクションの下の違反のビューを提供します。サンプルレポートは次のとおりです。

違反をクリックすると、違反が発生したファイルの正確な行に移動します。

5. カスタムチェックスタイル構成

Mavenレポート生成セクション(セクション2.2)では、カスタム構成ファイルを使用して、独自のコーディング標準チェックを実行しました。

パッケージ化されたGoogleまたはSunのチェックを使用したくない場合は、独自のカスタム構成XMLファイルを作成する方法があります。

上記のチェックに使用されるカスタム構成ファイルは次のとおりです。

<!DOCTYPE module PUBLIC
  "-//Puppy Crawl//DTD Check Configuration 1.3//EN"
  "http://www.puppycrawl.com/dtds/configuration_1_3.dtd">
<module name="Checker">
    <module name="TreeWalker">
        <module name="AvoidStarImport">
            <property name="severity" value="warning" />
        </module>
    </module>
</module>

5.1. DOCTYPE定義

ieの最初の行 DOCTYPE定義はファイルの重要な部分であり、システムが構成を理解できるように、どこからDTDをダウンロードするかを指示します。

この定義を構成ファイルに含めないと、有効な構成ファイルにはなりません。

5.2. モジュール

設定ファイルは主にモジュールで構成されています。 モジュールには、モジュールの機能を表す属性名があります。 name 属性の値は、プラグインの実行時に実行されるプラグインのコード内のクラスに対応します。

上記の構成に存在するさまざまなモジュールについて学びましょう。

5.3. モジュールの詳細

  • チェッカー:モジュールは、ルートにチェッカーモジュールがあるツリーで構造化されています。 このモジュールは、構成の他のすべてのモジュールによって継承されるプロパティを定義します。
  • TreeWalker:このモジュールは、個々のJavaソースファイルをチェックし、そのようなファイルのチェックに適用できるプロパティを定義します。
  • AvoidStarImport:このモジュールは、Javaコードでスターインポートを使用しないための標準を設定します。 また、プラグインに警告などの問題の重大度を報告するように要求するプロパティもあります。 したがって、そのような違反がコードで見つかった場合は常に、警告のフラグが立てられます。

カスタム構成の詳細については、このリンクを参照してください。

6. Spring-Restプロジェクトのレポート分析

このセクションでは、例としてGitHubで利用可能なspring-restプロジェクトで、上記のセクション5で作成したカスタム構成を使用して、Checkstyleによって実行された分析に光を当てます。

6.1. 違反レポートの生成

構成をEclipseIDEにインポートしました。これは、プロジェクトに対して生成される違反レポートです。

ここで報告されている警告は、コードではワイルドカードのインポートを避ける必要があることを示しています。 この標準に準拠していないファイルが2つあります。 警告をクリックすると、違反のあるJavaファイルが表示されます。

HeavyResourceController.javaファイルに報告された警告がどのように表示されるかを次に示します。

6.2. 問題の解決

Starインポートの使用は、2つ以上のパッケージに同じクラスが含まれている場合に競合が発生する可能性があるため、一般的には適切な方法ではありません。

例として、クラス List、whichがパッケージjava.utiljava.awtの両方で利用可能であると考えてください。 java.util。*とjava.awt。*の両方のインポートを使用すると、リストがで利用可能であるため、コンパイラはコードのコンパイルに失敗します。両方のパッケージ。

上記の問題を解決するために、両方のファイルにインポートを整理して保存します。プラグインを再度実行すると、違反は表示されず、コードはカスタム構成で設定された標準に準拠しています。 。

7. 結論

この記事では、CheckstyleをJavaプロジェクトに統合するための基本について説明しました。

これは、開発者が組織によって設定されたコーディング標準に準拠していることを確認するために使用される、シンプルでありながら強力なツールであることを学びました。

静的分析に使用したサンプルコードは、GitHubから入手できます。