概要
命名とは「呼び方」ではない。
それは**“構造の意図・責務の区別・ロジックの役割を伝えるための最小の設計記述”**である。
悪い命名は読み手の理解を妨げ、保守を困難にし、設計の意図を曖昧にする。
良い命名は構造を明示し、責務を区別し、コードそのものがドキュメントとして機能する。
本稿では、命名の型、粒度、接頭辞の戦略、構造的命名の一貫性設計を解説する。
1. 動詞 vs 名詞：関数とデータの基本分離
const user = { id: 'u01', name: 'Toto' }; // 名詞：データ
function fetchUser() { ... } // 動詞：操作
- ✅ データ → 名詞、操作 → 動詞 を厳密に使い分ける
- ✅
getUser/setUser/updateUserなど 動詞は行為を明示する
2. 接頭辞で責務を明示する（プレフィックス戦略）
- get → 値を取得する（同期）
- fetch → 値を取得する（非同期）
- create → 新しいエンティティを生成
- is / has / can → booleanを返す
function isValidEmail(email: string): boolean
function fetchUserList(): Promise<User[]>
- ✅ 読んだ瞬間に返り値と動作が予測できる
3. UIコンポーネント命名：構造と再利用性を示す
- Button → 汎用ボタン
- SubmitButton → 特定用途（送信）
- UserCard → 特定データ構造表示用
- ✅ 汎用コンポーネント → 単語ベース
- ✅ 特化コンポーネント → ドメイン名 or 機能 + 構造名の複合
4. ユースケース・ドメイン操作の命名
createUserAccount
updateUserEmail
deleteUserSession
- ✅ ドメイン + 操作名 の構造で責務を明確に
- ❌
handleSomething/doTask→ 意味が希薄
5. 命名の粒度：意味を保持したまま短縮する
| NG名 | 改善案 | 理由 |
|---|---|---|
res |
response or apiResponse
|
意図が曖昧、文脈依存 |
d |
data or userData
|
意味の不在 |
list |
userList / todoList
|
単語が抽象的すぎる |
- ✅ 「短い = 良い」ではなく、「意味が保たれている = 良い」
6. 名前の一貫性は設計の一貫性
- getUser → fetchUser に統一（非同期）
- isActive → hasActiveUser → canActivate
- ✅ プロジェクト全体で “動詞セットの選定と統一” を行う
- ✅ 命名は個人スタイルではなく、設計スタイル
設計判断フロー
① その名前は構造を語っているか？ → 意味が文脈依存でないか確認
② データ vs 関数で名詞と動詞が区別されているか？
③ 接頭辞が一貫して使われているか？ → 命名規約を定義
④ UIコンポーネントが再利用性を反映しているか？
⑤ 命名の粒度がプロジェクト全体で統一されているか？
よくあるミスと対策
❌ handleData, doStuff, processInfo のような曖昧な動詞
→ ✅ 「何を」+「どうする」まで書く：sendUserData, sortByDate
❌ 命名が短すぎて意味を失う（res, x, temp）
→ ✅ ドメイン・構造・意図を最小限含めた名前に
❌ 命名が属人化・一貫性がなくなる
→ ✅ 接頭辞・ドメイン名・役割ごとの命名ルールを明文化
結語
命名とは「名前をつけること」ではない。
それは**“構造を語り、意図を伝え、責任を明示するための設計の言語”**である。
- 動詞と名詞で役割を分け
- 接頭辞で責務を区別し
- 一貫した命名で構造を美しく保つ
JavaScriptにおける命名戦略とは、
“コードそのものが設計書となるための言語的戦略”である。