コードの命名

名前は、そのコードを読む全員が最初に読む説明文である。名前が処理を語らなければ、読み手は本体を読むまで何も分からず、コストも副作用も見誤る。

適用範囲

• 本スキルが決めるのは語の選び方だけ。大文字小文字の書式（キャメルケース／スネークケース／パスカルケース）は、言語とプロジェクトの規約に従う。
• プロジェクトにコーディング規約がある場合、規約全体はそちらを優先する。ただし命名については本スキルを優先する。
• 次の2つは本スキルより優先する。名前を選ぶ余地が無いため。
  1. 言語機能として要求される名前（プロパティ、アクセサ、特殊メソッド、テストの命名規約など）
  2. 標準ライブラリ・フレームワーク・外部ライブラリが既に定めている名前
• 新しく書く名前に適用する。 既存の名前は、改名が依頼の範囲に含まれるときだけ直す。範囲外の一括改名は、変更差分を膨らませてレビューを困難にする。

名前を決める手順

1. 何をするものかを日本語で1文にする。 「〜を取得する」で終わるなら、まだ処理を理解できていない。どこから、どうやって、その結果何が起きるかまで書く。
2. その1文の動詞を英語の動詞に置き換える。 迷ったら references/verbs.md から選ぶ。
3. 対象を名詞で書く。 汎用的すぎないかを規則3で確認する。
4. 修飾語が要るかを判断する。 時間軸・状態・不確実性などは references/modifiers.md を見る。
5. 声に出して読む。 英文として成立しない名前は、読み手の頭の中でも成立しない。真偽値なら if の条件に置いて読む。

規則

1. get を新しく書かない

「取得する」は処理の内容を何も語らない。データベースを引くのか、計算するのか、保持済みの値を返すのか、外部サービスを呼ぶのかが名前から消え、呼び出し側がコストと失敗の可能性を見誤る。

何をして値を得るのかを動詞にする。

やること	動詞
保存先から読み込む	load
ネットワーク越しに取りに行く	fetch
条件に合うものを探す	find / search
一覧をまとめて返す	list
材料から組み立てる	build / compose
計算して求める	calculate / count
複数の材料から1つに決める	resolve / determine
別の形に変換して返す	to〜 / convert
中から一部を取り出す	extract
無ければ作って返す	findOrCreate

例外は適用範囲に挙げた2つ（言語機能としてのアクセサ、既存ライブラリが定めた名前）だけ。それ以外で get を書きたくなったら、手順1に戻って処理を1文で説明し直す。

2. 処理の重さを名前で偽らない

軽い名前（値を返すだけに見える名前）の中に、入出力・ネットワーク通信・繰り返し処理を入れない。逆に、読み込むだけの処理に重い印象の動詞を付けない。名前と実際のコストがずれると、呼び出し側がループの中で呼んでしまう。

3. 目的に沿った名前にする（目的駆動名前設計）

Product（商品）のように広い名前は、予約・注文・在庫・発送のあらゆるロジックを引き寄せ、1つのクラスが肥大する。何の関心事を扱うのかを名前に入れる。

• Product → ReservedItem（予約） / StockItem（在庫） / ShippingItem（発送）
• 名前を分けることが、そのまま責務を分けることになる。

次の語は、責務が定まらないまま何でも入る器になりやすい。使う前に、何をするものかを名詞で言い直す。

避ける語	直し方
〜Manager / 〜Controller（MVC の Controller を除く）	何を管理するのかを動詞化して分割する
〜Util / 〜Helper	対象となる型の名前を冠した専用クラスにする
〜Data / 〜Info / 〜Item / 〜Type	外して意味が通るなら外す。通らないなら中身が定まっていない
data / result / temp / flag	実際に入っているものを書く（isSuccess / newId / mappedRows など）

4. 真偽値は if の条件として英文になる形にする

判定基準は1つ。== true を付けないと文として成立しない名前は使わない。

型	例
is + 形容詞／過去分詞	isEmpty / isChanged
has + 名詞／過去分詞	hasObservers / hasSent
can + 動詞の原形	canUpdate
should + 動詞の原形	shouldRetry
needs + 名詞／動詞	needsMigration
三人称単数の動詞（＋名詞）	exists / contains / existsError

避ける形は3つ。check〜（真のとき何が起きるのかが読めない）、is + 動詞の原形（isFail ではなく isFailed）、原形の動詞 + 名詞（existError ではなく existsError）。

詳細と反例は references/booleans.md。

5. 意味の広すぎる動詞を避ける

check / change / process / handle / manage / do は、何が起きるのかを読み手に想像させる。実際の動作を書く。

• checkUser → validateUser / userExists / isUserActive
• changeStatus → activateUser / cancelOrder / markAsRead
• processOrder → chargeOrder / shipOrder

比較する compare も結果の意味が読めない。equals / contains / isOlderThan のように、判定結果が名前で決まる形にする。

6. 対になる操作は対になる語で書く

片方だけ別系統の語を使うと、対応関係が読めなくなる。

add / remove、insert / delete、create / destroy、open / close、start / stop、enable / disable、show / hide、lock / unlock、push / pop、connect / disconnect、attach / detach、acquire / release、encode / decode、publish / subscribe

7. 省略しない

一文字の変数名と、その分野で確立していない略語を使わない。nm は name か number か読み手には分からない。

例外は、ごく短い範囲のループ変数（i など）と、確立した略語（id / url / http / db / json）。

8. 品詞を揃える

• クラス・型・変数は名詞、関数・メソッドは動詞から始める。
• インタフェースは、性質を表す形容詞（Iterable / Closeable）か、役割を表す名詞（〜Repository / 〜Sender）にする。
• 配列・コレクションは複数形、その要素は単数形にする（buttons の要素は button）。
• コールバックは、いつ呼ばれるかを名前に入れる（onCompleted / beforeUpdate / afterSave）。

書き上げたあとのチェック

• get で始まる新しい名前が残っていないか
• 名前だけ読んで、入出力・ネットワーク通信の有無が判断できるか
• クラス名・型名が広すぎて、複数の関心事のロジックが入り込んでいないか
• 真偽値の名前を if の条件に置いて読んだとき、英文として成立するか
• check / change / data / result / temp / flag が残っていないか
• 対になる操作が、対になる語で書かれているか
• 略語・一文字の名前が、範囲を超えて使われていないか
• 複数形と単数形が、実際の中身と一致しているか
• 同じ意味に複数の語を混在させていないか（fetch と load を同じ意味で併用していないか）

リファレンス

• references/verbs.md — 動詞の使い分け。値を得る／作る／保存する／消す／探す／変換する／検査する／非同期／コレクション操作。
• references/booleans.md — 真偽値の命名6型と反例3型、否定形の扱い。
• references/class-names.md — クラス・インタフェースの役割を表す名詞。層ごとの語彙と、避けるべき名前。
• references/modifiers.md — 修飾語。時間軸・階層・状態・数量・不確実性・注意喚起。

出典

以下を突き合わせて整理した。原典に当たる必要が生じたときはここを見る。

• プログラミングでよく使う英単語のまとめ https://qiita.com/Ted-HM/items/7dde25dcffae4cdc7923
• メソッド名の付け方 https://qiita.com/KeithYokoma/items/2193cf79ba76563e3db6
• クラス名の付け方 https://qiita.com/KeithYokoma/items/ee21fec6a3ebb5d1e9a8
• Boolean 型の命名 https://qiita.com/uehiro22/items/7a2b0b3b72f458018632
• JavaScript の命名テクニック 初級編 https://ics.media/entry/220915/
• JavaScript の命名テクニック 上級編 https://ics.media/entry/220929/
• 規則3の「目的駆動名前設計」は『良いコード／悪いコードで学ぶ設計入門』（仙塲大也）第10章の考え方による。