チェックスタイル vs.PMD

https://stackoverflow.com/questions/184563

06-07-2019
|

質問

私たちは Java 製品のビルドシステムに静的分析ツールを導入しています。Maven2を使用しているので、チェックスタイルそして PMD 統合は無料で提供されます。ただし、基本的なスタイルルールを強制するという点では、これら 2 つのツールの機能には大きな重複があるようです。

これらの両方を活用することでメリットはありますか?1 つが機能する場合は 2 つのツールを保守したくありません。どちらかを選択する場合、どれを使用する必要がありますか?またその理由は何ですか?

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

アップデート： CheckStyle よりも PMD の方が好ましいというのがコンセンサスのようです。両方を使用する明確な理由は見当たらず、2 セットのルールファイルを維持したくないため、おそらく PMD のみを使用することになるでしょう。また、アーキテクチャルールを強制するために FindBugs を導入し、最終的には Macker も導入する予定です。

解決

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

CheckstyleとPMDの場合、Checkstyleはスタイルにのみ関係しているため、使用しません。私の経験では、Checkstyleは完全に無関係な多くのことを報告します。一方、PMDは、疑わしいコーディング手法を指摘することもでき、その出力は一般により関連性が高く有用です。

他のヒント

どちらのソフトウェアも便利です。 Checkstyleは、プログラミング中にコーディングスタイル（ブレース、ネーミングなど）を確認するのに役立ちます。単純なことですが、非常に多数あります！

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

をチェックします

ただし、どちらのソフトウェアも、説明が不適切な場合がある類似のルールに悩まされています。構成が不適切な場合、2回または2回反対のことを確認できます。つまり、「不要なコンストラクターを削除する」および「常に1つのコンストラクター」。

いずれかを選択した場合、どちらを使用する必要があり、なぜですか？

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

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

チェックスタイルの例：

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

PMDは悪い習慣を思い出させます：

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

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

両方を使用します：

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

主な使用場所がEclipseでの開発である場合、InstantiationsのCodeProが最適です。以前は商用ツールでしたが、今ではGoogleがInstantiationsを購入したため、CodeProアナリティックスは現在無料です。

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

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

とはいえ、Findbugsには最も具体的またはニッチなルールがあり（たとえば、「IllegalMonitorStateExceptionの疑わしいキャッチ-どのくらいの頻度でそれに遭遇する可能性が高いか？」）真剣に。 CheckstyleとPMDでは、ルールはより一般的でスタイルに関連しているため、カスタムコンフィグレーションファイルでのみ使用して、無関係なフィードバックの雪崩からチームを解放する必要があります（「5行目のタブ文字」、「6行目のタブ文字」 ;、＆quot; Tab char on line 7quot; ...写真が表示されます）。また、独自の高度なルールを作成するための強力なツールも提供します。 Checkstyle DescendentToken ルール。

3つすべてを使用する場合（特にSonarのようなツールを使用する場合）、重複を防ぐために注意を払いながら（3つすべてのツールがそのhashCode（）がオーバーライドされ、equals（）ではありません。たとえば）。

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

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

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

CheckstyleとPMDはどちらもコーディング標準のチェックに優れており、拡張が容易です。ただし、PMDには、循環的な複雑さ、Npathの複雑さなどをチェックする追加のルールがあり、健全なコードを記述できます。

PM Neal Fordはメトリック駆動型アジャイル開発、 Java / Java EE開発に役立つ多くのツールについて説明しています

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

FindBugsを使用することを強くお勧めします。バイトコードレベルで機能するため、ソースレベルでは不可能なことを確認できます。かなりの数のジャンクを吐き出しますが、コードに多くの実際の重要なバグが見つかりました。

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

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

また、Checkstyle＆quot; import control＆quot;この機能はMackerに必要なものをカバーし、PMD / Mackerの代わりにPMD / Checkstyleを実装できます。どちらにしても2つのツールですが、Checkstyleを使用すると、PMDがすぐに使用できる「無料」の機能を取得できます。

これまでのところ私が見ていない点の 1 つは、コードに CheckStyle ルールセットを強制する IDE のプラグインがあるのに対し、PMD プラグインは違反のみを報告するということです。たとえば、複数のプログラミングチームにまたがるマルチサイトプロジェクトでは、標準について報告するだけでなく、標準を積極的に施行することが重要です。

どちらのツールにも、IntelliJ、NetBeans、および Eclipse で使用できるプラグインがあります (私の考えでは、これでほとんどの用途がカバーされます)。私は NetBeans には詳しくないので、IntelliJ と Eclipse についてのみコメントできます。

とにかく、IntelliJ および Eclipse の PMD プラグインはレポートを生成します。 オンデマンド プロジェクトのコードベース内の PMD 違反について。

一方、CheckStyle プラグインは、その場で違反を強調表示し、一部の問題 (例:'OneStatementPerLine' の場合はステートメントの間に CR-LF を配置し、'NeedBraces' の場合は欠けているところに中括弧を追加します。など)。明らかに、自動的に修正できるのは単純な違反だけですが、レガシープロジェクトや複数の場所にまたがるプロジェクトでは依然として役立ちます。

PMD の「オンデマンド」とは、開発者がレポートの実行を意識的に決定する必要があることを意味します。一方、Checkstyle 違反は、その発展に応じて自動的に報告されます。PMD中するより広範なルールセットが含まれているため、IDE での違反の自動強制/報告は、2 セットのルールを維持する手間をかける価値があると私は考えています。

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

そして10年後... 2018年には、それらすべてをCheckstyle、PMD、およびFindBugsで使用します。

FindBugs から始めます。後でPMDとCheckstyleを追加するかもしれません。

デフォルトのルールを盲目的に施行しない！

手順：

多くのコードを持つプロジェクトでデフォルトのルールを使用して1つのツールを実行します
ルールをこのプロジェクトに適合させ、無用なルールをコメントでコメントアウトします
ローハンギングフルーツルール（NPE、ロガーチェック、非クローズリソースチェックなど）に焦点を当てる
価値のあるルールをいくつか修正します（一度に1つずつ！）
ツールごとにこれを行いますが、一度にすべてではありません！
このプロセスを繰り返します

理想的には、各プロジェクトに個別のルールを設定できます。ビルド（mavenプラグイン経由）でルールを実行するのが好きで、プロジェクトが定義したすべてのルールに合格すると、ルールエラーで失敗します。 報告だけでは十分ではないため、開発者は行動を起こす必要があります。プロジェクトのその時点からは、ほとんど防弾であり、後でルールを追加したり、カスタムルールを記述したりすることもできます。

qulice-maven-plugin をご覧ください。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>

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

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

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

PMDは、チェックスタイルと比較した場合の最も優れたツールです。 Checkstylesにはコードを分析する機能がない場合がありますが、PMDは多くの機能を提供しています。 Offcourse PMDは、javadoc、コメント、インデントなどのルールをリリースしていません。そして、ちなみに、これらのルールの実装を計画しています。......thanx

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow