コードレビューでスタイル指摘が多いのは、実は組織内での「何を重視するか」の認識のズレが原因だと感じています。私も以前、指摘の種類で悩んだ時期がありました。

変わるきっかけになったのは、レビュアーに直接「この指摘は修正必須ですか、それとも参考意見ですか」と聞くようにしたことです。すると、スタイル指摘の中にも「後々のバグに繋がりやすいパターン」と「単なるチーム慣例の話」が混在していることに気づきました。前者は機能の信頼性に直結するので、本質的な問題。後者は一貫性の問題で、どちらかといえば保守性の話です。

個人的には、以下のように分けるようにしています。まず、ロジックの正確性や例外処理漏れなど「動作に関わる指摘」は明らかに本質的。次に、変数名や関数分割の粒度は「微妙なライン」で、チーム規模や複雑性によって判断が変わります。最後に、インデント幅やブレースの位置といった純粋なフォーマットは「自動化で解決すべき」だと考えるようになりました。

レビュアーとのコミュニケーションを増やすことで、スタイル指摘の背景にある実際の懸念を理解しやすくなりました。その結果、指摘自体は変わらなくても、自分がそれにどう対応するかが随分と変わりましたね。