CheckStyleの紹介

CheckStyleの概要

1. 概要

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

このチュートリアルでは、how to integrate Checkstyle into a Java project via Maven and by using IDE plugins.を見ていきます。

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

2. CheckstyleMavenプラグイン

2.1. Mavenの構成

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


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

This plugin comes with two predefined checks, a Sun-style check, and a Google-style check。 プロジェクトのデフォルトのチェックはsun_checks.xml.です

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

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

2.2. レポート生成

Mavenプラグインが構成されたので、mvn siteコマンドを実行してコードのレポートを生成できます。 Once the build finishes, the report is available in the target/site folder under the name checkstyle.html.

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

Files:レポートのこのセクションでは、the list of files in which the violations have happenedを提供します。 また、重大度レベルに対する違反の数も表示されます。 レポートのファイルセクションは次のようになります。

image

Rules:レポートのこの部分は、overview of the rules that were used to check for violationsを提供します。 ルールのカテゴリ、違反の数、およびそれらの違反の重大度が表示されます。 次に、ルールセクションを示すレポートのサンプルを示します。

image

Details:最後に、レポートの詳細セクションにdetails of the violations that have happenedが表示されます。 提供される詳細は行番号レベルです。 レポートの詳細セクションのサンプルは次のとおりです。

image

2.3. ビルド統合

コーディングスタイルを厳密にチェックする必要がある場合は、we can configure the plugin in such a way that the build fails when the code doesn’t adhere to the standards.

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


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

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

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

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

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

3. Eclipseプラグイン

3.1. 構成

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

構成をインポートするには、Window → Preferences → Checkstyle.に移動します。Global Check Configurationsセクションで、New.をクリックします。

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

3.2. レポートの閲覧

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

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

The plugin will give us feedback on our Java code within the Eclipse, text editor.Eclipseでビューとして利用できるプロジェクトの違反レポートも生成します。

違反レポートを表示するには、Window → Show View → Otherに移動し、Checkstyleを検索します。 ViolationsおよびViolations Chartのオプションが表示されます。

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

image

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

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

Eclipse IDEの問題ビューのサンプルを次に示します。

image

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

4. IntelliJ IDEAプラグイン

4.1. 設定

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

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

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

4.2. レポートの閲覧

プラグインが構成されたので、それを使用して違反をチェックしましょう。 特定のプロジェクトの違反を確認するには、Analyze → Inspect Code.に移動します

The Inspections Results will give us a view of the violations under the Checkstyle section.サンプルレポートは次のとおりです。

image

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

5. カスタムCheckstyle構成

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

パッケージ化されたGoogleまたはSunの小切手を使用したくない場合はWe have a way to create our own custom configuration XML file

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



    
        
            
        
    

5.1. DOCTYPE定義

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

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

5.2. モジュール

構成ファイルは、主にモジュールで構成されています。 A module has an attribute name which represents what the module does.name属性の値は、プラグインの実行時に実行されるプラグインのコード内のクラスに対応します。

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

5.3. モジュールの詳細

  • Checker:モジュールは、ルートにCheckerモジュールがあるツリーで構成されています。 このモジュールは、構成の他のすべてのモジュールによって継承されるプロパティを定義します。

  • TreeWalker:このモジュールは、個々のJavaソースファイルをチェックし、そのようなファイルのチェックに適用できるプロパティを定義します。

  • AvoidStarImport:このモジュールは、Javaコードでスターインポートを使用しないための標準を設定します。 また、このような問題の重大度を警告として報告するようプラグインに要求するプロパティもあります。 したがって、このような違反がコード内で見つかると、警告が警告されます。

カスタム構成の詳細については、このlinkに従ってください。

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

このセクションでは、例としてspring-rest project available on GitHubについて、上記のセクション5で作成したカスタム構成を使用して、Checkstyleによって実行された分析に光を当てます。

6.1. 違反レポートの生成

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

image

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

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

image

6.2. 問題解決

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

例として、isがパッケージjava.utiljava.awtの両方で使用可能なクラスList,について考えてみます。 java.util。*とjava.awt.*の両方のインポートを使用すると、Listが両方のパッケージで使用できるため、コンパイラーはコードのコンパイルに失敗します。

To resolve the issue mentioned above we organize the imports in both files and save them.これで、プラグインを再度実行しても違反は見られず、コードはカスタム構成で設定された標準に準拠しています。

7. 結論

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

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

静的分析に使用したサンプルコードは、over on GitHubで利用できます。