naming｜コードレビューにおける命名の重要性と判断基準
naming｜コードレビューにおける命名の重要性と判断基準
概要
namingは、コードレビューにおける最も本質的かつ繰り返し指摘されるテーマの一つです。
変数・関数・クラス・ファイル名など、命名の質はコードの可読性・意図の明示・変更コストに直結します。
優れた命名はコメントや補足を不要にし、コードそのものが「仕様書」になります。
命名の判断基準とは何か
命名に関するレビューは「好み」の議論に見えがちですが、実際には以下のような技術的な観点で判断されるべきです：
| 判断軸 | 内容例 |
|---|---|
| 意図の明示性 | 名前から機能や役割が推測できるか（例：calculateTax） |
| 一貫性 | チーム内の命名規則と揃っているか |
| 文脈との整合性 | 近くの変数名・関数名との関係性が明確か |
| スコープ対応 | ローカル／グローバル／クラス内で役割が重複していないか |
| 語彙の適切性 | 誤訳や造語、曖昧な表現になっていないか（例：data1 など） |
よくある命名レビューの実例
曖昧な命名
const a = getUserInfo();レビューコメント例：
naming: `a` では意味が不明です。`userInfo`など、役割を反映した名前にしましょう。意図が明確な命名
const activeUserList = getUserInfo();関数名や変数名には「名詞＋目的語」「動詞＋対象」の形を意識すると意図が伝わりやすくなります。
命名と設計意図のズレに注意
関数やクラスの命名がその中身とずれている場合、読み手に誤解を与えます。
例：createUser() が内部でDB保存までしているなら registerUser() の方が妥当です。
命名ミスは単なる表記揺れではなく、設計意図の齟齬を示す危険信号でもあります。
命名の伝播関係
命名レビューのコミュニケーション例
Reviewer: この関数名、doActionだと内容が曖昧すぎませんか？
Author: たしかに処理が増えてきたので、機能分割＋renameします。Reviewer: この変数、`info`ってだけだと型の内容が見えません。
Author: `userDetail`に変えます。指摘ありがとうございます。命名のレビュー文化をチームに定着させるには
- 共通の命名規則をドキュメント化（例：
camelCase,PascalCase, 動詞名詞のルール） - ESLintや型定義の補助で命名基準を自動チェック
- PRテンプレートに「命名妥当性」の確認項目を加える
- 命名提案時には「why」もコメントで補足
レビューコメントに「命名が曖昧」だけでなく、「どう変えると意図が伝わるか」まで書くと納得感が増します。
まとめ
命名は可読性・保守性・チームの共通理解に直結する「コードの顔」です。
表面だけを見て揶揄的に指摘するのではなく、機能意図・設計背景・文脈といった構造的視点から命名を捉えることで、レビューの質が変わります。