java - Checkstyle 対 PMD

Question

Java 製品のビルドシステムに静的解析ツールを導入しています。Maven2 を使用しているため、CheckstyleとPMDの統合は無料です。ただし、基本的なスタイルルールを適用するという点では、これら 2 つのツールの機能には大きな重複があるようです。

これらの両方を使用する利点はありますか？1 つが機能する場合、2 つのツールを維持したくありません。どちらかを選択する場合、どれを使用する必要がありますか?また、その理由は何ですか?

FindBugs の使用も計画しています。他に検討すべき静的解析ツールはありますか?

更新: PMD が CheckStyle よりも優先されるというコンセンサスがあるようです。両方を使用する確固たる理由はわかりません。また、2 セットのルールファイルを維持したくないので、おそらく PMD のみを対象とします。また、FindBugs を導入し、最終的には Macker を導入してアーキテクチャルールを適用する予定です。

score 78 · Accepted Answer

間違いなくFindBugsを使用する必要があります。私の経験では、誤検知率は非常に低く、報告される重要度の低い警告でさえ、ある程度対処する価値があります。

Checkstyle と PMD については、Checkstyle はほとんどスタイルのみに関係しているため、私は Checkstyle を使用しません。私の経験では、Checkstyle はまったく関係のない大量のレポートを作成します。一方、PMD は疑わしいコーディングプラクティスを指摘することもでき、その出力は一般的に関連性が高く有用です。

score 41 · Accepted Answer

どちらのソフトウェアも便利です。Checkstyle は、コーディングスタイル(ブレース、名前付けなど)をチェックすることにより、プログラミング中に役立ちます。単純なことですが、非常に多くあります。

PMD は、クラスの設計中などのより複雑なルールをチェックしたり、クローン機能を正しく実装するなどのより特別な問題をチェックしたりするのに役立ちます。簡単に言うと、PMD がプログラミングスタイルをチェックします。

ただし、両方のソフトウェアには、よく説明されていない同様のルールがあります。構成が悪いと、「不要なコンストラクターを削除する」と「常に 1 つのコンストラクター」という反対のことを 2 回または 2 回チェックすることがあります。

score 25 · Accepted Answer

いずれかを選択した場合、どちらを使用する必要がありますか。その理由は何ですか。

これらのツールは競合していませんが、補完的であり、同時に使用する必要があります。

コンベンションタイプ（Checkstyle）は、一貫性のないコードを理解するために時間とエネルギーを費やす代わりに、人々が協力して創造性を解放できるようにする接着剤です。

Checkstyleの例：

パブリックメソッドに関するjavadocはありますか？
プロジェクトはSunの命名規則に従っていますか？
コードは一貫した形式で書かれていますか？

PMDはあなたに悪い習慣を思い出させますが：

何もせずに例外をキャッチする
デッドコードがある
複雑な方法が多すぎる
インターフェイスの代わりに実装を直接使用する
not equals（Object object）メソッドなしでhashcode（）メソッドを実装する

ソース： http： //www.sonarsource.org/what-makes-checkstyle-pmd-findbugs-and-macker-complementary/

score 15 · Accepted Answer

両方を使用します。

スタイルをチェックして、チームの全員が同じような方法でコードを書いていることを確認します
問題のあるコード領域と次のリファクタリングターゲットを見つけるための PMD

score 7 · Accepted Answer

主な使用場所が Eclipse での開発である場合は、Instantiations の CodePro が最適です。以前は商用ツールでしたが、Google が Instantiations を買収したため、CodePro analytix は無料になりました。

http://code.google.com/javadevtools/download-codepro.htmlをご覧ください

score 7 · Accepted Answer

Checkstyle、PMD、および Findbugs のルールリストを確認すると、3 つすべてが価値のある出力を提供し、3 つすべてがある程度重複しており、独自の独自のルールをテーブルに持ち込んでいることがわかります。これが、Sonar のようなツールが 3 つすべてを使用する理由です。

とは言っても、Findbugs には最も具体的またはニッチなルール (たとえば、「IllegalMonitorStateException の疑わしいキャッチ」-どのくらいの頻度でそれに遭遇する可能性がありますか?) があるため、構成をほとんどまたはまったく行わずに使用でき、その警告を真剣に受け止める必要があります。Checkstyle と PMD では、ルールはより一般的でスタイルに関連しているため、チームを無関係なフィードバックの雪崩から守るために、カスタム構成ファイルでのみ使用する必要があります (「5 行目のタブ文字」、「6 行目のタブ文字」、「7行目のタブ文字」...あなたは写真を手に入れます）。また、Checkstyle DescendentTokenルールなど、独自の高度なルールを作成するための強力なツールも提供します。

3 つすべてを使用する場合 (特に Sonar などのツールを使用する場合)、それらすべてを個別に構成する必要があります (すべてのルールをカバーするには少なくとも数日かかります) が、重複を防ぐために注意を払います (3 つのツールはすべて hashCode() が検出されたことを検出します)。たとえば、overridden と equals() not)。

要約すると、静的コード分析が価値があると考える場合、3 つのいずれかが提供する値を拒否することは意味がありませんが、3 つすべてを使用するには、使用可能なフィードバックを提供するように構成するために時間を費やす必要があります。

score 6 · Accepted Answer

Sonar (http://www.sonarsource.org/) は、コード品質を管理するための非常に便利なオープンプラットフォームであり、Checkstyle、PMD、Findbugs などが含まれています。

これは、3 つのツールすべてに存在する権利があることも示しています...

score 5 · Accepted Answer

どちらのツールも構成可能で、ほぼ同じことができます。とは言っても、すぐに使用できるものについて話している場合、多くの重複がありますが、明確なルール/チェックもあります. たとえば、Checkstyle は Javadoc のチェックやマジックナンバーの検索などを強力にサポートしています。さらに、Checkstyle には Macker の機能に似た「インポートコントロール」機能があります (私は Macker を使用していません)。

PMD ではなく Checkstyle がすぐに実行できる重要な事柄がある場合は、それらのチェックのみを備えた最小限の Checkstyle 構成を検討することができます。次に、Checkstyle 構成が拡張できないポリシーを設定します。たとえば、カスタム PMD ルールを使用して同様の機能を実装するときに、チェックを削除するだけです。

また、Checkstyle の「インポートコントロール」機能が Macker に必要なものをカバーすると判断した場合は、PMD/Macker の代わりに PMD/Checkstyle を実装できます。どちらにしても 2 つのツールですが、Checkstyle を使用すると、PMD がすぐに使用できない機能を「無料で」入手できます。

score 4 · Accepted Answer

Checkstyle と PMD は、スタイルの問題と単純で明白なコーディングのバグを強化するのに最適だと思います。私は Eclipse とそれが提供するすべての警告を使用するのが好きであることがわかりましたが、その目的により適しています。共有設定を使用し、それらを実際のエラーとしてマークすることで、強制します。そうすれば、そもそもチェックインされることはありません。

私が強く熱心にお勧めするのは、FindBugs の使用です。バイトコードレベルで動作するため、ソースレベルでは不可能なことをチェックできます。ジャンクのかなりの割合を吐き出す一方で、コード内に多くの実際の重要なバグを発見しました。

score 3 · Accepted Answer

Checkstyle、PMD、FindBugs、およびその他のいくつかの静的アナライザーを組み合わせて、それらを事前構成するqulice-maven-pluginを見てください。この組み合わせの利点は、すべてのプロジェクトで個別に構成する必要がないことです。

<plugin>
  <groupId>com.qulice</groupId>
  <artifactId>qulice-maven-plugin</artifactId>
  <version>0.15</version>
  <executions>
    <execution>
      <goals>
        <goal>check</goal>
      </goals>
    </execution>
  </executions>
</plugin>

score 3 · Accepted Answer

これまでに見たことのない点の 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 セットのルールを維持する手間をかける価値があります。

そのため、私が取り組んでいるプロジェクトでは、IDE で適用される Checkstyle、IDE で報告される PMD、およびビルドで報告および測定される (Jenkins による)両方のツールを使用します。

score 2 · Accepted Answer

PMD が Java スタイル/規則チェックの最新の製品であるというコメントを繰り返します。FindBugs に関しては、多くの商用開発グループが Coverity を使用しています。

score 1 · Accepted Answer

PMD は、より多くの人が参照しているものです。Checkstyle は 4 年前に人々が言及していたものでしたが、PMD はより継続的に維持され、他の IDE/プラグインが使用することを選択したと思います。

score 1 · Accepted Answer

Checkstyle と PMD を使い始めたばかりです。私にとって、PMD は、まったく難しくない XPath クエリを記述できる限り、System.gc()、Runtime.gc() が存在するかどうかなどのカスタマイズされたルールを作成する方が簡単です。ただし、PMD は、列番号を表示する機能があることを示していません。したがって、列の制限を確認するなどの場合。Checkstyle を使用することをお勧めします。

score -2 · Accepted Answer

PMD は、checkstyles と比較して最も優れたツールです。チェックスタイルにはコードを分析する機能がないかもしれませんが、PMD には分析するための多くの機能があります。オフコースPMDは、javadoc、コメント、インデントなどのルールをリリースしていません。ちなみに、これらのルールを実装する予定です........ありがとうございます

java - Checkstyle 対 PMD

17 に答える 17

Related

Reference