メインコンテンツまでスキップ

.NET Code Analysis (CA)

.NETのコード分析（Code Analysis）は、コードの品質、スタイル、パフォーマンス、セキュリティの問題を検出し、開発の初期段階で修正するための静的解析機能です。現代の.NET開発では、Roslynコンパイラプラットフォームに基づいた「Roslyn Analyzers」が標準的に使用されています。

Code Analysis (CA) とは​

Code Analysisは、コンパイル時にソースコードを検査し、潜在的なバグやコーディング規約違反を報告する仕組みです。

主な特徴​

  • リアルタイムフィードバック: Visual StudioやVS CodeなどのIDEで、コードを書いている最中に警告やエラーが表示されます。
  • ビルド時の検証: CI/CDパイプライン上でコードの品質を強制することができます。
  • カスタマイズ可能: ルールの有効/無効や重大度（Severity）を細かく設定できます。

従来のFxCopとの違い​

かつては「FxCop」と呼ばれる静的解析ツールが使われていましたが、現在はRoslyn Analyzers（.NET Analyzer）に統合されています。FxCopはコンパイル後のアセンブリを解析していましたが、Roslyn Analyzersはソースコードを解析するため、よりリッチで高速なフィードバックが可能です。

ルールの種類​

.NET SDKには数多くの分析ルールが含まれています。これらは主に以下のカテゴリに分類されます。

1. コード品質ルール (CAxxxx)​

API設計、セキュリティ、パフォーマンス、信頼性などの問題を検出します。

  • Design: ライブラリ設計のガイドラインに従っているか（例: インターフェイスの実装方法）。
  • Performance: パフォーマンスに悪影響を与えるコードを検出（例: 不必要な文字列連結）。
  • Security: セキュリティホールになり得る脆弱なコードを検出。
  • Reliability: アプリケーションの動作を不安定にする可能性のある記述を検出。
  • Usage: Frameworkの正しい使用方法に関わるルール。

2. コードスタイルルール (IDExxxx)​

コードの可読性やフォーマットの一貫性に関わるルールです。

  • var の使用方針
  • 中括弧 {} の省略可否
  • 名前空間の宣言スタイル（File-scoped namespaceなど）

3. サードパーティ製アナライザー​

NuGetパッケージとして導入できる追加のアナライザーもあります。

  • StyleCop.Analyzers: 厳しいスタイルガイドラインを適用したい場合。
  • SonarAnalyzer.CSharp: SonarQube準拠の詳細な解析。
  • xUnit.Analyzers: テストコード専用のベストプラクティスチェック。

設定と構成​

.NETのコード分析の動作は、主にプロジェクトファイル（.csproj）と.editorconfigファイルで制御します。

プロジェクトファイルでの設定​

プロジェクト全体に対する分析レベルを設定します。

<PropertyGroup>
  <!-- すべての警告をエラーとして扱う（推奨） -->
  <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
  
  <!-- .NETのコード分析機能を有効化（.NET 5以降はデフォルトでtrue） -->
  <EnableNETAnalyzers>true</EnableNETAnalyzers>
  
  <!-- 分析レベルの指定（latestは最新のSDK推奨設定を使用） -->
  <AnalysisLevel>latest</AnalysisLevel>
  
  <!-- 推奨設定をすべて有効にするかどうか -->
  <AnalysisMode>All</AnalysisMode>
</PropertyGroup>

.editorconfig による詳細設定​

.editorconfig を使用すると、個別のルールごとに重大度（Severity）を設定できます。リポジトリのルートに配置することで、すべてのプロジェクトに適用されます。

重大度 (Severity) のレベル​

  • error: ビルドを失敗させる。直ちに修正が必要。
  • warning: ビルドは成功するが警告を表示する（TreatWarningsAsErrorsが有効ならビルド失敗）。
  • suggestion: IDE上で「・・・」のようなヒントを表示する。ビルドログには残らない。
  • silent: エディタ上での強調表示はしないが、修正案（電球アイコン）としては利用可能。
  • none: ルールを無効にする。

設定例​

# .editorconfig

# ファイルごとの設定
[*.cs]

#### コア分析ルール ####

# CA1062: パブリックメソッドの引数のnullチェックを検証
dotnet_diagnostic.CA1062.severity = error

# CA1822: 静的メンバーとしてマークできるメンバーを指摘
dotnet_diagnostic.CA1822.severity = warning

# CA2007: ConfigureAwait を使用するかどうかのチェック（ASP.NET Coreでは不要なので無効化）
dotnet_diagnostic.CA2007.severity = none

#### スタイルルール ####

# var の使用を強制 (csharp_style_var_for_built_in_types)
csharp_style_var_for_built_in_types = true:suggestion

# File-scoped namespaceの使用を推奨
csharp_style_namespace_declarations = file_scoped:warning

ベストプラクティス​

1. 警告ゼロを目指す (TreatWarningsAsErrors)​

本番品質のコードでは、<TreatWarningsAsErrors>true</TreatWarningsAsErrors> を設定し、警告をエラーとして扱うことを推奨します。警告を放置すると、重要な問題が見逃される「割れ窓理論」のような状態になります。

2. .editorconfig を階層的に管理する​

  • ルートディレクトリ: 全体共通の厳格なルール。
  • テストプロジェクト: 一部のルール（命名規則やドキュメント要否など）を緩和する設定で上書きする。

3. AnalysisLevel の定期更新​

.NET SDK のアップデートに伴い、新しいルールが追加されます。<AnalysisLevel>latest</AnalysisLevel> にしておくと自動的に新しいルールが適用されますが、SDK更新時にビルドが壊れるリスクがあります。安定性を重視する場合は <AnalysisLevel>8.0</AnalysisLevel> のようにバージョンを固定し、計画的にバージョンを上げましょう。

4. チームでの合意形成​

すべてのルールを有効にすると開発速度が落ちる可能性があります。チームにとって「ノイズ」となるルールは躊躇なく none に設定し、本当に守るべきルールだけを error や warning に設定しましょう。

まとめ​

適切なコード分析の導入は、コードレビューの負担を減らし、品質を自動的に担保するための強力な手段です。.NET標準の機能と .editorconfig を活用して、チームに合った解析環境を構築しましょう。

関連リソース​