【2026年最新】命名規則の決め方7原則｜迷わないための判断基準

変数や関数の名前を考える時間は、書く時間より長くなることがあります。規則が決まっていないと、担当者ごとにばらつき、後から読む人が余計な負担を負います。この記事では、規則を決めるときの原則と、迷ったときの判断基準を整理します。

7つの原則

【結論】読み手を基準に考えてください。

1. 省略しない

文字数を惜しんで略すと、読む人が推測することになります。補完機能がある現在、長さの負担はほとんどありません。広く知られた略語だけを使ってください。

2. 役割を表す

何を保持しているか、何をするかが分かる名前にします。データという名前では、何のデータか分かりません。

3. 嘘をつかない

一覧を保持しているのに単数形にする、取得するだけの関数に更新という語を使う、といった不一致は避けてください。名前と実態がずれると、読む人が誤解します。

4. 一貫させる

同じ概念には同じ語を使ってください。取得を意味する語が箇所によって違うと、別のものかと考えさせます。

5. 対になる語を揃える

開始と終了、追加と削除、最小と最大。反対の意味を持つ組み合わせは、慣用的な対を使ってください。

6. 型を名前に含めない

文字列であることを名前に含める書き方は、型が変わったときに実態とずれます。現在の言語では型が明示されるため不要です。

7. 検索できる名前にする

1文字の変数は検索できません。ごく短い範囲でしか使わない場合を除き、意味のある名前を付けてください。

避けたい名前	望ましい名前	理由
data	userProfile	何のデータか分かる
tmp	swapTarget	役割が分かる
flg	isPublished	省略せず、真偽が分かる
getUserAndSave	分割する	1つの役割に絞る
list1, list2	activeUsers, archivedUsers	区別がつく

種類ごとの考え方

【結論】品詞で使い分けます。

変数

名詞にします。何を保持しているかを表すためです。複数を保持するなら複数形にしてください。

関数

動詞から始めます。何をするかを表します。取得するなら取得を意味する語、判定するなら判定を意味する語で始めてください。

真偽値

是非を問う形にします。条件文に置いたときに自然な文になるかを基準にすると決めやすくなります。

定数

大文字と下線で区切る形式が慣用的です。変わらない値であることが一目で分かります。

クラス

名詞にします。役割を表す語を選び、管理や処理といった曖昧な語だけで終えないでください。

表記の形式

【結論】言語の慣習に従ってください。

言語ごとの標準

単語の区切りを大文字にする形式、下線でつなぐ形式など、言語ごとに広く使われる書き方があります。まずそれに従ってください。

独自の規則を作らない

言語の慣習と違う書き方をすると、外部のライブラリと混在したときに読みにくくなります。

ファイル名も統一する

変数名だけでなく、ファイル名やディレクトリ名にも規則を適用してください。大文字と小文字の扱いが環境で異なる点にも注意が必要です。

自動整形の活用

形式を機械的に検査する道具を導入すれば、指摘が自動化されます。人が指摘すると角が立ちますが、道具なら摩擦がありません。

迷ったときの判断

【結論】声に出して読んでください。

文として自然か

条件文や代入文として読んだとき、自然な文になるかを確認します。不自然なら、名前が役割と合っていません。

説明が必要か

名前を見た人に説明が必要なら、名前が不十分です。コメントで補うより、名前を変えるほうが確実です。

他の候補と比べる

3つほど候補を出して、最も誤解の少ないものを選んでください。1つ目で決めると、後から違和感が出ることがあります。

後から変えられる

完璧な名前を最初から付ける必要はありません。理解が深まったら変更してください。編集機能を使えば安全に変えられます。

チームで決めるとき

【結論】議論より文書化です。

短い文書にまとめる

長い規約は読まれません。数ページに収め、例を多く載せてください。

例を示す

抽象的な原則より、良い例と悪い例を並べるほうが伝わります。

用語集を作る

その分野の言葉を、どの語で表すかを決めておきます。同じ概念に複数の語が使われる状態を防げます。

変更の手順

規則を変えたくなったときの相談先を決めておいてください。個人の判断で変えると、統一が崩れます。

既存のコードとの整合

【結論】混在させないでください。

周りに合わせる

既存のコードに手を入れるとき、そのファイルの書き方に合わせてください。1か所だけ違う書き方が混ざると読みにくくなります。

一括で変える場合

全体を新しい規則に統一するなら、まとめて変更してください。段階的に変えると、混在期間が長く続きます。

外部との境界

外部のサービスから受け取る値は、相手の形式に従います。自分のコードへ取り込む段階で、自分の規則に変換してください。

変更の記録

名前だけを変える作業は、機能の変更と分けて記録してください。混ぜると、後から差分を追いにくくなります。

よくある質問（FAQ）

Q1. 名前が長くなりすぎます

役割が多すぎる可能性があります。分割を検討してください。

Q2. 日本語のローマ字表記でもよいですか

対応する英単語がない固有名詞なら妥当です。一般的な概念には英単語を使うほうが伝わります。

Q3. 1文字の変数は駄目ですか

数行で完結する範囲なら許容されます。慣用的に使われる文字もあります。

Q4. 規則が決まっていない場合は

既存のコードに合わせてください。そのうえで、規則を決める提案をしてもよいでしょう。

Q5. 略語はどこまで使えますか

その分野で誰もが知っているものに限ってください。判断に迷うなら省略しないほうが安全です。

Q6. 名前を変えると影響が大きいのでは

編集機能を使えば、参照箇所をまとめて変更できます。テストがあれば確認もできます。

まとめ

命名の原則は、省略しない、役割を表す、嘘をつかないの3つに集約されます。読む人が名前だけで内容を推測できることが目標です。

変数は名詞、関数は動詞から始める、真偽値は是非を問う形にするといった品詞の使い分けを守ると、迷う場面が減ります。

表記の形式は、言語ごとの慣習に従ってください。独自の規則を作ると、外部のライブラリと混在したときに読みにくくなります。機械的に検査する道具を入れれば、指摘が自動化されて摩擦もありません。

チームで決めるときは、長い規約より短い文書と多くの例が有効です。既存のコードに手を入れる際は、そのファイルの書き方に合わせてください。混在が最も読みにくい状態です。

📱 運営の裏側・最新情報はXで発信中 → @ore_chusotsu