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

Visual Studioのコード分析について聞いたことがありますが、使用しませんでした。私はMSDNを読みましたが、それでもコード分析の実際の使用法を理解していません。

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

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

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

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

コード分​​析（以前の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クラスを記憶する）のは退屈かもしれません。

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

静的分析ツールと同様、誤検知の影響を受けますが、抑制を使用せずにビジネスクリティカルなコードの警告をゼロにすることは通常有益です。Visual Studio内では、コンパイル時に実行するようにコード分析を構成できます。プロジェクトの設定で、警告をエラーとして扱うように指定されている場合、コード分析ルールの違反は気づかれることはありません。

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

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

StyleCopと同様に、プロジェクトの最初からコード分析によるゼロ警告をプロジェクトがターゲットとするかどうかを決定することが不可欠です。既存のプロジェクトに導入するのは苦痛かもしれません。

StyleCopとは違うのですか？

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

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

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

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

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

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