web-dev-qa-db-ja.com

コード分​​析の目的は何ですか？いつ使用する必要がありますか？

Visual Studioのコード分析について聞きましたが、使用していません。私は [〜＃〜] msdn [〜＃〜] を読みましたが、それでもコード分析の実際の使用法を理解していません。

それはStyleCopと同じではありませんか？

どこかで、FxCopも言及されました。コード分​​析との違いは何ですか？

すべてのプロジェクトでコード分析を使用する必要がありますか？同僚によるコードレビューは不十分ですか？

c#.netcode-qualitystatic-analysis
26
Arseni Mourzenko

コード分​​析とは何ですか？

コード分析 （以前のFxCop）は 静的分析 を検索するツールです 共通パターン は、ソースコードに問題があることを示している可能性があります。たとえば、IDisposableを実装するクラスのインスタンスが適切に破棄されていない場合、コード分析は警告を発します。

private void DoSomething()
{
    var connection = new SqlConnection(...);
    this.ChangeSomeData(connection);
}

これは前のコードの正しい実装です：

private void DoSomething()
{
    using (var connection = new SqlConnection(...))
    {
        this.ChangeSomeData(connection);
    }
}

他の静的分析ツールと同様に、コード分析は手動で見つけるのが面倒（または単純に退屈）なパターンを見つけることを目的としています。たとえば、前の例では、開発者が使用するクラスがIDisposableを実装しているかどうかを確認するのは（またはそれを実装するすべての.NET Frameworkクラスを覚えておくのは）退屈な場合があります。

どのプロジェクトが対象ですか？

他の静的分析ツールと同様に、誤検知が発生する可能性がありますが、通常、 suppressions を使用せずに、ビジネスクリティカルなコードに対してゼロ警告を対象とすることは有益です。 Visual Studio内では、コンパイル時に実行するようにコード分析を構成できます。プロジェクト設定で警告をエラーとして扱う必要があることも指定されている場合、コード分析ルールの違反は見過ごされません。

中規模または大規模なプロジェクトでは静的分析に時間がかかる場合があるため、開発者のマシンからTFSビルドサーバーに静的分析を移動することをお勧めします。コミット前のコード分析の実行中は 非推奨 （StyleCopとは異なり）ですが、警告が見つかった場合はビルド時に実行され、失敗する可能性があります。

ビジネスクリティカルでないコードの場合、コード分析は手動で実行できます Visual Studioから またはコマンドライン。チェックと警告は、プロジェクトプロパティで細かくしてニーズに合わせることができます。たとえば、プロジェクトがローカライズされることを意図していない場合、 グローバリゼーション警告 をオフにすることができます。

StyleCopと同様に、プロジェクトがコード分析のゼロ警告をプロジェクトの最初から対象とするかどうかを決定することが重要です。 既存のプロジェクトでそれを導入するのは、あまりにも面倒かもしれません。

StyleCopとは違うのですか？

コード分​​析は StyleCop と同じではないことに注意してください。最初の違いは、コード分析はコンパイルされたアセンブリで機能するのに対し、StyleCopはソース自体で機能することです。 2番目の（そして最も重要な）違いは、CodeCがバグを示している可能性のあるパターンを検索するのに対し、StyleCopは単にスタイルルール（チームが使用する単純な規則）を適用することです。

コード分析は、言語をよく知らない初心者にも特に役立ちます。これは、「Aha！」につながることが多いためです。瞬間。たとえば、 CA2105：配列フィールドは読み取り専用であってはなりません は、配列が読み取り専用としてマークされていても、変更を禁止するものがないため、不変にならないという発見につながる可能性があります配列内の要素。 StyleCopが発見につながることはありません。フィールドが小文字で始まることや、ローカル呼び出しの前にthisを付ける必要があることを理解しても、何も興味深いことはありません。

コード分​​析とStyleCopの両方でいくつかのルールが適用されている場合でも（ CA1707：識別子にアンダースコアを含めることはできません 対 SA1310：フィールド名にアンダースコアを含めることはできません ）、これらの2つのツールは補完的であり、しばしば並べて使用されます。

すでにコードレビューがあります

コードレビューの存在は、コード分析を回避する理由ではありません。コード分​​析とStyleCopはどちらも自動的に物事を見つけるのに優れていますbeforeコードレビュー。コードのレビューに費やして、スタイルの問題や自動的に検出された可能性のある問題のあるパターンを特定することほど悪いことはありません。面白いもののためにコードレビューを保管してください。

もう1つの側面は、人間のレビュー担当者は、コード分析で見つかった問題の発見が必ずしも得意ではないということです。たとえば、IDisposableを実装するクラスのインスタンスが1つの場所に作成され、別の場所に配置される場合があります。校閲者がそれを見つけるのに少し時間がかかりますが、静的分析ツールがそれを発見するのに数ミリ秒しかかかりません。

36
Arseni Mourzenko