Java プロジェクトでどのコード分析ツールを使用していますか?
いろんなことに興味があります
該当する場合は、使用しているビルド ツールと、これらのツールが IDE とビルド ツールの両方とどの程度うまく統合されているかについても説明してください。
ツールが特定の方法 (IDE プラグイン、またはビルド ツール プラグインなど) でしか利用できない場合、その情報も注目に値します。
静的分析ツールには、CPD、PMD、FindBugs、およびCheckstyleをよく使用します。
CPDは、PMDの「コピー/貼り付け検出器」ツールです。PMD Webページの「重複コードの検索」リンクに気付く前に、しばらくの間PMDを使用していました。
これらのツールは、「すぐに使える」一連のルールを超えて拡張できる場合があることを指摘したいと思います。そして、それらがオープンソースであるという理由だけでなく、それらを書き直すことができます。これらのツールの一部には、拡張を可能にするアプリケーションまたは「フック」が付属しています。たとえば、PMDには、新しいルールを作成できる「デザイナ」ツールが付属しています。また、Checkstyleには、大幅なカスタマイズを可能にするプロパティを持つDescendantTokenチェックがあります。
これらのツールをAntベースのビルドと統合します。リンクをたどると、コメントされた構成を確認できます。
ビルドへの単純な統合に加えて、他のいくつかの方法でツールをある程度「統合」するように構成すると便利です。つまり、レポートの生成と警告の抑制の均一性。これらの側面をこのディスカッションに追加したいと思います（おそらく「静的分析」タグも必要です）：「統一された」ソリューションを作成するために、これらのツールをどのように構成しているのでしょうか。（私はここで別々にこの質問をしました）
まず、警告レポートの場合、各警告が単純な形式になるように出力を変換します。
/absolute-path/filename:line-number:column-number: warning(tool-name): messageこれはしばしば「Emacsフォーマット」と呼ばれますが、Emacsを使用していない場合でも、レポートを均質化するための妥当なフォーマットです。例えば：
/project/src/com/example/Foo.java:425:9: warning(Checkstyle):Missing a Javadoc comment.警告形式の変換は、Antフィルターチェーンを使用したAntスクリプトによって行われます。
私が行う2番目の「統合」は、警告の抑制です。デフォルトでは、各ツールは、無視したい警告を消音するためにコードに配置できるコメントまたは注釈（あるいはその両方）をサポートしています。しかし、これらのさまざまな警告抑制要求は、一貫した外観を持たず、ややばかげているように見えます。警告を抑制しているときは、警告を抑制しているので、常に「SuppressWarning？」と書いてはいけません。
たとえば、PMDのデフォルト設定NOPMDでは、コメントに文字列「」が含まれるコード行での警告の生成が抑制されています。また、PMDはJavaの@SuppressWarnings注釈をサポートしています。PMD抑制が同じように見えるように、SuppressWarning(PMD.代わりに「」を含むコメントを使用するようにPMDを構成します。NOPMDコメントスタイル抑制を使用するときに違反する特定のルールを入力します。
// SuppressWarnings(PMD.PreserveStackTrace) justification: (false positive) exceptions are chainedコメントにとって重要なのは「」の部分だけですが、名前で個々のルール違反を認識する注釈に対するSuppressWarnings(PMD.PMDのサポートと一致しています。@SuppressWarning
@SuppressWarnings("PMD.CompareObjectsWithEquals") // justification: identity comparision intended同様に、Checkstyleは、コメントのペア間の警告の生成を抑制します（注釈のサポートは提供されません）。デフォルトでは、Checkstyleをオフおよびオンにするコメントには、それぞれ文字列CHECKSTYLE:OFFとが含まれていますCHECKSTYLE:ON。この構成を（Checkstyleの「SuppressionCommentFilter」を使用して）文字列「BEGIN SuppressWarnings(CheckStyle.」および「END SuppressWarnings(CheckStyle.」を使用するように変更すると、コントロールがPMDのようになります。
// BEGIN SuppressWarnings(Checkstyle.HiddenField) justification: "Effective Java," 2nd ed., Bloch, Item 2// END SuppressWarnings(Checkstyle.HiddenField)
Checkstyleコメントでは、各チェックに独自の " "コメントペアがあるため、特定のチェック違反（ HiddenField）は重要です。BEGIN/END
FindBugsは、注釈付きの警告生成抑制もサポートしている@SuppressWarningsため、他のツールとある程度の均一性を実現するために、これ以上の構成は必要ありません。残念ながら、Findbugsはカスタム@SuppressWarningsアノテーションをサポートする必要があります。これは、組み込みのJava@SuppressWarningsアノテーションには、SOURCEFindBugsが必要とするクラスファイルにアノテーションを保持するのに十分な強度がない保持ポリシーがあるためです。@SuppressWarningsJavaのアノテーションとの衝突を避けるために、FindBugsの警告抑制を完全に修飾します。
@edu.umd.cs.findbugs.annotations.SuppressWarnings("UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR")これらの手法により、ツール間で物事が合理的に一貫しているように見えます。各警告抑制に文字列" SuppressWarnings"が含まれていると、コードベース全体ですべてのツールのすべてのインスタンスを見つけるための簡単な検索を簡単に実行できることに注意してください。
Cobertura、Checkstyle、(Ecl)Emma、Findbugs を組み合わせて使用しています。
EclEmmaは素晴らしいEclipse プラグインで、エディターで Java ソースに色を付けてコード カバレッジを表示します (スクリーンショット)。カバレッジは JUnit テストを実行することによって生成されます。これは、特定のクラスでどの行がカバーされているかを把握しようとしている場合や、単一のテストでどの行がカバーされているかを確認したい場合に非常に役立ちます。これは、レポートを生成してからレポートを調べて、どのクラスのカバレッジが低いかを確認するよりも、はるかにユーザーフレンドリーで便利です。
Checkstyle および Findbugs Eclipse プラグインも便利です。これらは、入力時にエディターで警告を生成します。
Maven2 には、上記のツールと連携してビルド時にレポートを生成するレポート プラグインがあります。これを使用して、全体的なプロジェクト レポートを取得します。これは、集計値が必要な場合により便利です。これらは、Continuumを使用して実行される CI ビルドによって生成されます。
All of the following we use and integrate easiy in both our Maven 2.x builds and Eclipse/RAD 7:
In addition, in our Maven builds we have:
Furthermore, if you're using Maven 2.x, CodeHaus has a collection of handy Maven plugins in their Mojo project.
Note: Clover has out-of-the-box integration with the Bamboo CI server (since they're both Atlassian products). There are also Bamboo plugins for FindBugs, PMD, and CheckStyle but, as noted, the free Hudson CI server has those too.
IntelliJ IDEA に組み込まれている静的分析を使用します。完璧な統合。
Intellij IDEA (EMMA ベース) に組み込まれているコード カバレッジを使用します。繰り返しますが、完全な統合です。
この統合ソリューションは、さまざまなベンダーのツールを組み合わせるよりも、信頼性が高く、強力で使いやすいものです。
Checkstyleは、私が前の会社で使用したもう 1 つのツールです。主にスタイル チェック用ですが、静的分析も実行できます。また、コード カバレッジ用のCloverもありますが、無料のツールではないことに注意してください。
コード カバレッジには、FindBugs と Checkstyle、および Clover を使用しています。
開発をサポートする、ある種の静的分析を行うことが重要だと思います。残念ながら、これらのツールの重要性はまだ広く普及していません。
私はコベルトゥーラと幸運に恵まれました。これは、通常のビルドの一部としてantスクリプトを介して実行でき、Hudsonに統合できるコードカバレッジツールです。
私たちのプロジェクトでは、checkstyle、pmd の前に Sonar を使用しています。CI (Bamboo、Hudson) と一緒に、ソースの品質とどのような指示を行っているかについての素晴らしい履歴も取得します。私が Sonar を気に入っているのは、CI スタックの 1 つの中心的なツールがそれを実行してくれ、各プロジェクトのルールを簡単にカスタマイズできるからです。
Ant と統合された FindBugs と JDepend を使用します。JUnit を使用していますが、カバレッジ ツールは使用していません。
Rational Application Developer (J2EE アプリケーションの開発に使用している IDE) に統合して使用していません。Windows コンソールで javac を実行したときの見栄えが良いからです。:P
私たちのチームは PMD と Cobertura を使用しています。実際、私たちのプロジェクトは Maven プロジェクトであり、コード分析用のプラグインを含めるのは非常に簡単です。本当の問題は、どの分析を使用する必要がある特定のプロジェクトであるかということです。私の意見では、プロジェクトごとに同じプラグインを使用することはできないということです。
Structure 101は、コード分析と循環パッケージの依存関係の発見に優れています。
新しいツールについて学び、この知識を 1 つの質問/スレッドに統合するための多くの回答を探しているので、この質問に対する真の回答が 1 つあるとは思えません。
私自身の質問に対する私の答えは、次のものを使用することです。
Hudson には、TODO と FIXME の数を表示し、ソース ファイルのどこにあるかを表示するタスク スキャナー プラグインもあります。
私たちの場合、すべてが Maven 1.x と統合され、Hudson に結び付けられています。Hudson は、チェックイン時にビルドを実行するだけでなく、毎晩および毎週追加のものを実行します。Hudson トレンドは、JUnit テスト、カバレッジ、findbug、および未解決のタスクをグラフ化します。コンパイル警告を報告およびグラフ化する Hudson プラグインもあります。また、ハドソン プロット プラグインを使用して、時間の経過に伴うパフォーマンスとメモリ使用量の独自のグラフを使用したいくつかのパフォーマンス テストもあります。
