Java製品のビルドシステムに静的分析ツールを導入しています。Maven2を使用しているため、CheckstyleとPMDの統合は無料です。ただし、基本的なスタイルルールを適用するという点では、これら2つのツールの機能には大きな重複があるようです。
これらの両方を利用することには利点がありますか？1つが機能する場合、2つのツールを維持したくありません。いずれかを選択した場合、どちらを使用する必要がありますか。その理由は何ですか。
FindBugsの使用も計画しています。他に検討すべき静的分析ツールはありますか？
更新：コンセンサスは、PMDがCheckStyleよりも優先されるということのようです。両方を使用する確固たる理由はわかりません。また、2セットのルールファイルを維持したくないので、おそらくPMDのみを目指します。また、FindBugsを導入し、最終的にはMackerを導入してアーキテクチャルールを適用します。
回答:
あなたは間違いなくFindBugsを使うべきです。私の経験では、偽陽性率は非常に低く、それが報告する最も重要度の低い警告でさえ、ある程度対処する価値があります。
CheckstyleとPMDについては、スタイルのみに関係しているため、Checkstyleは使用しません。私の経験では、Checkstyleは完全に無関係なものをたくさん報告します。一方、PMDは疑わしいコーディング手法を指摘することもでき、その出力は一般により関連性が高く、有用です。
どちらのソフトウェアも便利です。Checkstyleは、中括弧や名前付けなどのコーディングスタイルをチェックすることで、プログラミング中に役立ちます。単純なことですが、非常に多くあります。
PMDは、クラスの設計中などのより複雑なルールをチェックしたり、クローン関数を正しく実装するなどのより特別な問題をチェックしたりすることで役立ちます。簡単に言えば、PMDはあなたのプログラミングスタイルをチェックします
ただし、どちらのソフトウェアも同様のルールに悩まされていることがあります。設定が悪いと、「役に立たないコンストラクターを削除する」と「常に1つのコンストラクター」という2回または2つの反対のことをチェックする可能性があります。
いずれかを選択した場合、どちらを使用する必要がありますか。その理由は何ですか。
これらのツールは競合していませんが、補完的であり、同時に使用する必要があります。
コンベンションタイプ（Checkstyle）は、一貫性のないコードを理解するために時間とエネルギーを費やす代わりに、人々が協力して創造性を解放できるようにする接着剤です。
Checkstyleの例：
PMDはあなたに悪い習慣を思い出させますが：
ソース：http： //www.sonarsource.org/what-makes-checkstyle-pmd-findbugs-and-macker-complementary/
主な使用場所がEclipseでの開発中の場合は、InstantiationsのCodeProが最適です。以前は商用ツールでしたが、現在GoogleがInstantiationsを購入したため、CodeProanalytixは無料になりました。
http://code.google.com/javadevtools/download-codepro.htmlをチェックして ください
Checkstyle、PMD、Findbugsのルールリストを確認すると、3つすべてが価値のある出力を提供し、3つすべてがある程度重複し、独自の独自のルールをテーブルにもたらすことがわかりました。これが、Sonarのようなツールが3つすべてを使用する理由です。
とは言うものの、Findbugsには最も具体的またはニッチなルール（「IllegalMonitorStateExceptionの疑わしいキャッチ-どのくらいの頻度でそれに遭遇する可能性がありますか？」など）があるため、設定をほとんどまたはまったく行わずに使用でき、警告を真剣に受け止める必要があります。CheckstyleとPMDを使用すると、ルールはより一般的でスタイルに関連するため、カスタム構成ファイルでのみ使用して、チームを無関係なフィードバックの雪崩から保護する必要があります（「5行目のタブ文字」、「6行目のタブ文字」、 「7行目のタブ文字」...画像が表示されます）。また、Checkstyle DescendentTokenルールなど、独自の高度なルールを作成するための強力なツールも提供します。
3つすべてを使用する場合（特にSonarなどのツールで）、重複を防ぐように注意しながら、すべてを個別に構成する必要があります（すべてのルールをカバーするのに少なくとも数日かかります）（3つのツールすべてがhashCode（）がたとえば、オーバーライドされ、equals（）ではありません）。
要約すると、静的コード分析が価値があると考える場合、3つのいずれかの値を拒否することは意味がありませんが、3つすべてを使用するには、使用可能なフィードバックを提供するように構成するために時間を費やす必要があります。
どちらのツールも構成可能であり、ほぼ同じことを実行できます。とは言うものの、すぐに使えるものについて話している場合、かなりの重複がありますが、明確なルール/チェックもあります。たとえば、Checkstyleは、Javadocのチェックとマジックナンバーの検索をより強力にサポートしています。さらに、Checkstyleには、Mackerの機能に似た「インポート制御」機能があります（私はMackerを使用していません）。
Checkstyleがすぐに実行でき、PMDが実行できない重要なことがある場合は、それらのチェックのみを使用した最小限のCheckstyle構成を検討することをお勧めします。次に、Checkstyle構成を拡張できないポリシーを設定します。たとえば、カスタムPMDルールを使用して同様の機能を実装する場合は、チェックを削除するだけです。
また、Checkstyleの「インポート制御」機能がMackerに必要なものをカバーしていると判断した場合は、PMD / Mackerの代わりにPMD / Checkstyleを実装できることも考慮してください。いずれにせよ、これは2つのツールですが、Checkstyleを使用すると、PMDがすぐに実行できない機能を「無料で」入手できます。
CheckstyleとPMDはどちらもコーディング標準のチェックに優れており、簡単に拡張できます。ただし、PMDには、循環的複雑度、Npathの複雑度などをチェックするための追加のルールがあり、正常なコードを記述できます。
PMDを使用するもう1つの利点は、CPD（Copy / Paste Detector）です。プロジェクト間でのコードの重複を検出し、JAVAに制限されません。JSPでも機能します。Neal Fordは、メトリクス駆動型アジャイル開発に関する優れたプレゼンテーションを行っています。これは、Java / JavaEE開発に役立つ多くのツールについて説明しています。
CheckstyleとPMDは、スタイルの問題と単純な明らかなコーディングのバグを強制するのに最適だと思います。私はEclipseとすべての警告を使用するのが好きだとわかりましたが、その目的にはEclipseの方が適しています。共有設定を使用し、実際のエラーとしてマークすることで、内容を強制します。そうすれば、そもそもチェックインされることはありません。
私が強くそして熱心に推奨するのは、FindBugsを使用することです。バイトコードレベルで動作するため、ソースレベルでは不可能なことをチェックできます。ジャンクのかなりの部分を吐き出しますが、コードに実際の重要なバグがたくさん見つかりました。
そして10年後... 2018年に私はそれらすべてをCheckstyle、PMD、FindBugsで使用しています。
FindBugsから始めましょうます。後でPMDとCheckstyleを追加するかもしれません。
デフォルトのルールをやみくもに強制しないでください！
手順：
理想的には、各プロジェクトに個別のルールを設定できます。ビルド（mavenプラグイン）を介してルールを実行するのが好きで、プロジェクトが定義したすべてのルールに合格することがわかったら、ルールエラーで失敗します。これにより、レポートだけでは不十分なため、開発者はアクションを実行する必要があります。その時点から、プロジェクトはほとんど防弾になり、後でルールを追加したり、カスタムルールを作成したりすることもできます。
私がこれまで見たことがない1つのポイントは、コードにCheckStyleルールセットを適用するIDEのプラグインがあるのに対し、PMDプラグインは違反についてのみ報告するということです。たとえば、複数のプログラミングチームにまたがるマルチサイトプロジェクトでは、標準について報告するだけでなく、標準を積極的に実施することが重要です。
どちらのツールにも、IntelliJ、NetBeans、およびEclipseで使用できるプラグインがあります（私の見解では、これはほとんどの使用法をカバーしています）。私はNetBeansにあまり詳しくないので、IntelliJとEclipseについてのみコメントできます。
とにかく、IntelliJおよびEclipse用のPMDプラグインは、プロジェクトコードベース内のPMD違反についてオンデマンドでレポートを生成します。
一方、CheckStyleプラグインはその場で違反を強調表示し、いくつかの問題を自動的に変換するように構成できます（少なくとも、IntelliJの場合、Eclipseの経験は少ないです）（たとえば、「OneStatementPerLine」の場合、CR-LFを配置します） 'NeedBraces'の場合、ステートメント間では、欠落している場所に中括弧が追加されます。明らかに、より単純な違反のみが自動的に修正されますが、それでもレガシープロジェクト、または複数の場所にあるプロジェクトでは役立ちます。
PMDの「オンデマンド」とは、開発者が意識的にレポートを実行することを決定する必要があることを意味します。一方、Checkstyle違反は、発生時に自動的に報告されます。PMDにはより広範なルールセットが含まれていますが、私の考えでは、IDEでの違反の自動実行/報告は、2セットのルールを維持する手間をかける価値があります。
だから私たちは両方のツールを使用して、上で動作するすべてのプロジェクトのために、Checkstyleは、IDEで施行、PMDはIDEで報告され、両方がビルドで（ジェンキンス経由）に報告して測定しました。
見てくださいquliceを-のMavenプラグイン、一緒にそのコンバインのCheckstyle、PMD、FindBugsのといくつかの他の静的アナライザ、および事前に設定し、それらを。この組み合わせの利点は、すべてのプロジェクトで個別に構成する必要がないことです。
<plugin>
<groupId>com.qulice</groupId>
<artifactId>qulice-maven-plugin</artifactId>
<version>0.15</version>
<executions>
<execution>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
settings.jarは助けました。
PMDは、私がより多くの人が言及しているものです。Checkstyleは、4年前に人々が言及していたものでしたが、PMDはより継続的に維持され、他のIDE /プラグインが使用することを選択したと思います。