概要

命名とは「呼び方」ではない。
それは**“構造の意図・責務の区別・ロジックの役割を伝えるための最小の設計記述”**である。

悪い命名は読み手の理解を妨げ、保守を困難にし、設計の意図を曖昧にする。
良い命名は構造を明示し、責務を区別し、コードそのものがドキュメントとして機能する。

本稿では、命名の型、粒度、接頭辞の戦略、構造的命名の一貫性設計を解説する。

1. 動詞 vs 名詞：関数とデータの基本分離

const user = { id: 'u01', name: 'Toto' };     // 名詞：データ
function fetchUser() { ... }                 // 動詞：操作

- get → 値を取得する（同期）
- fetch → 値を取得する（非同期）
- create → 新しいエンティティを生成
- is / has / can → booleanを返す

function isValidEmail(email: string): boolean
function fetchUserList(): Promise<User[]>

- Button → 汎用ボタン
- SubmitButton → 特定用途（送信）
- UserCard → 特定データ構造表示用

createUserAccount  
updateUserEmail  
deleteUserSession

- getUser → fetchUser に統一（非同期）
- isActive → hasActiveUser → canActivate

① その名前は構造を語っているか？ → 意味が文脈依存でないか確認

② データ vs 関数で名詞と動詞が区別されているか？

③ 接頭辞が一貫して使われているか？ → 命名規約を定義

④ UIコンポーネントが再利用性を反映しているか？

⑤ 命名の粒度がプロジェクト全体で統一されているか？

→ ✅ 「何を」+「どうする」まで書く：sendUserData, sortByDate

→ ✅ ドメイン・構造・意図を最小限含めた名前に

→ ✅ 接頭辞・ドメイン名・役割ごとの命名ルールを明文化

命名とは「名前をつけること」ではない。
それは**“構造を語り、意図を伝え、責任を明示するための設計の言語”**である。

JavaScriptにおける命名戦略とは、
“コードそのものが設計書となるための言語的戦略”である。