命名レビューでトラウマ植え付けられてそうな新人に贈る処方箋
ポエム
新人教育
新人プログラマ応援
新人エンジニア
新人プログラマ応援_記事投稿キャンペーン
最終更新日 2025年05月13日
投稿日 2025年05月13日
はじめに
新人エンジニアのアナタがコードレビューで一番指摘されているのは「命名」に関することじゃなかろうか？
「この命名イケてないね」や「なんでこの命名にしたの？」なんて指摘を何往復もして、
「命名ごときでゴチャゴチャと吐かしてんじゃないｯ！」って腸が煮えくり返る気持ちになっていることだろう。
でも実は、命名こそがコードの要。
仕様を忘れた未来の自分、コードを読む同僚、保守を任された後輩──
彼らが最初に頼るのが「名前」なんです。
逆に言えば、命名をミスると全員が地雷を踏む。
命名は単なる飾りじゃなくて、コードの意味や意図を伝える大事な要素。
未来の自分やチームメンバーが理解しやすい名前をつけるための考え方をまとめてみた。
❌ NG命名①：「check」は曖昧すぎる（メソッド名編）
メソッド名に「check」を使っていると、何をチェックして何を返してるのかが曖昧になりがち。
public function checkUserStatus(User $user): bool
{
// ユーザーのステータスを確認する処理
}
これ、true なら「OK」なの？ 「NG」なの？
どういう条件で true なの？──読まなきゃわからん！
⭕ もっと語らせよう
状態を返すなら is や has を。
判定を返すなら can や should を使おう。
public function isUserActiveStatus(User $user): bool {}
public function canUserEditItem(User $user, Item $item): bool {}
メソッド名で意図が語られていれば、中身を開かなくても意味がつかめる。
読み手ファーストな名前づけを心がけよう。
❌ NG命名②：dataとかinfoとかlistとかつけるな（変数名編）
変数名でありがちな「data」や「info」や「list」。
一見それっぽいけど、何を表すデータなのかがまったく伝わらない。
$data = getData(); // 何のデータ？
$info = getInfo(); // どんな情報？
$list = getList(); // 何の一覧？
$array = getArray(); // 配列型であることを言われましても……
もちろん、前後のコードを読めば「これは〇〇のデータかな？」と推測はできる。
けど、それって読み手に余計な負荷をかけてるだけ。
命名は「読めばわかる」じゃなくて、「見ただけでわかる」が正義だ。
⭕ 生きた名前に変えよう（複数形も意識）
$userProfile = getUserProfile(); // ユーザーのプロフィール
$orderItems = getOrderItems(); // 注文に紐づくアイテム一覧
$availableProducts = getAvailableProducts(); // 購入可能な商品一覧
特にリストや配列を表す変数は、List や Array と名前につけるより、意味のある名詞＋複数形で表現したほうがはるかに伝わる。
$users = getActiveUsers(); // アクティブなユーザーたち
$categories = getVisibleCategories(); // 表示対象のカテゴリたち
「複数形で書けるものは、それだけで“リストっぽさ”が伝わる」。
データ構造ではなく、意味を語る命名を心がけよう。
❌ NG命名③：「not」は読む人を混乱させる（否定形は罠）
function isNotVerified(User $user): bool {}
この命名、「not」が入った瞬間に読みにくさ爆増。
if (!isNotVerified()) みたいに二重否定になったとき、