go-nolint-audit

Go Nolint 監査

Go のコードベースにある //nolint: ディレクティブを監査します。古くなった抑制（コードが変更され、lint ルールに該当しなくなったもの）や、安易な理由付け（抑制する代わりに元のコードを修正できるもの）を検出します。コメントを鵜呑みにせず、敵対的な議論を通じて、それぞれの理由付けを検証します。

前提条件の確認

go version 2>/dev/null && golangci-lint --version 2>/dev/null

go がインストールされていない場合は停止して報告してください。golangci-lint が見つからない場合は、次の手順を実行します。

• https://golangci-lint.run/welcome/install/ からインストールします

両方のツールが使用可能でない限り、先に進まないでください。

nolint ディレクティブの検出

grep -rn '//nolint' --include='*.go' . | grep -v vendor/

すべての形式に一致させます：//nolint（ルール指定なし）、//nolint:rule、//nolint:rule1,rule2。各ディレクティブについて、次の情報を取得します。

• ファイルと行番号
• 抑制されるルール、またはルールが指定されていない場合は「bare」
• 理由コメント（存在する場合は //nolint:rule // の後のテキスト）
• 前後のコードコンテキスト（約5行）

ルール指定のない //nolint はすべてを抑制するため、Phase 2 の対象として自動的にフラグを立てます。ディレクティブが1つも見つからない場合は、コードベースに問題がないことを報告して終了します。

Phase 1: 機械的な検証

ルール名を指定した各ディレクティブについて、抑制がまだ必要かどうかをテストします。対象のルールと併せて nolintlint を有効にします。

# v2 syntax (preferred):
golangci-lint run --enable-only=<rule>,nolintlint \
  --allow-parallel-runners <file>

# v1 syntax (if v2 unavailable):
golangci-lint run --disable-all --enable=<rule>,nolintlint \
  --allow-parallel-runners <file>

nolintlint がディレクティブを未使用と報告した場合、そのディレクティブは古くなっています。これにより、ソースファイルを変更せずに検証できます。複数のルールを指定したディレクティブ（//nolint:rule1,rule2）では、各ルールを個別にテストします。並列で実行するシェルコマンドは最大3つまでとします。必ず --allow-parallel-runners を使用します。

対象のルール以外の理由（ビルドエラー、依存関係の不足など）で golangci-lint が失敗した場合、そのディレクティブの検証をスキップし、「検証不可」と報告します。

各ディレクティブを次のように分類します。

• 古い — ルールに該当しなくなっています。安全に削除できます。
• 有効 — ルールに引き続き該当します。Phase 2 に進みます。

古いディレクティブはすぐに報告します。すべてが古い場合は、Phase 2 をスキップします。ルール指定のない //nolint ディレクティブは Phase 1 をスキップします。特定のルールに対して検証できないためです。

Phase 2: 敵対的な議論

検出されたすべてのディレクティブを、Phase 1 のサンプルだけでなく、2つの観点で採点します（各1～5点）。大規模なコードベース（ディレクティブが50件以上）の場合、Phase 1 では異なるルールから5～10件をサンプルしますが、最も問題のあるものを見つけるため、ここでは全リストを採点します。

• 修正容易性 — 抑制する代わりにコードを修正するのはどれくらい簡単ですか？
  • 5 = ごく簡単（関数の切り出し、名前の変更、定数の追加）
  • 3 = 中程度（ロジックの再構成、関数の分割）
  • 1 = アーキテクチャの変更が必要
• 理由の妥当性 — コメントはどれくらい説得力がありますか？
  • 5 = コメントがない、または曖昧（「複雑さは避けられない」「必要」など）
  • 3 = 状況は説明しているが、修正するより抑制する方がよい理由は説明していない
  • 1 = 具体的で説得力のある理由

スコア = 修正容易性 x 理由の妥当性。採点の指針については references/go-nolint-patterns.md を参照してください。

スコア上位3件について議論します。

• Red（削除）：nolint を削除してコードを修正すべきだと主張します。具体的な差分を提示する必要があります。理由付けに異議を唱えます。
• Blue（維持）：nolint が適切だと主張します。既存のコメントに加えて、その理由を説明する必要があります。提案された修正のリスクを指摘します。
• White（判定）：根拠に基づいて評価し、削除、維持、または理由を改善のいずれかを決定します。

議論のルール

• Red と Blue は、一般論ではなく具体的なコードを根拠として示す必要があります
• Red は「もっと簡単にできる」だけでなく、具体的な差分を提示する必要があります
• Blue は既存の理由をそのまま繰り返すことはできません
• White の判定は最終決定です

出力形式

Phase 1

Stale (safe to remove):
  file.go:42  //nolint:errcheck — rule no longer triggers
  file.go:87  //nolint:mnd — rule no longer triggers

Unable to verify:
  file.go:99  //nolint:gosec — golangci-lint build error

Phase 2

議論する各ディレクティブについて：

#N: file.go:line — //nolint:rule

現在のコード（nolint を含む）： 前後のコードを5～10行

理由：「元のコメント」 削除した場合の lint 警告：[golangci-lint の出力を正確に記載]

Red（削除）：[主張 + 具体的な差分] Blue（維持）：[具体的な理由を含む主張] White（判定）：削除 | 維持 | 理由を改善 [理由]

[削除の場合：適用しやすいように差分を再掲] [理由を改善する場合：改善した理由を含む、置き換え後の行全体]

概要

#	ファイル：行	ルール	判定	作業量
1	location	rule	verdict	effort
2	location	rule	verdict	effort
3	location	rule	verdict	effort

古い項目：N（直ちに削除） | 検証不可：N