命名規則の使い分け｜私が命名で揉めた話と、落ち着いた結論

:::note ※命名規則で迷っている人のための「入口」記事です :::

命名規則は「好み」ではなく「設計」

命名規則の記事は山ほどある。でも「どれが正解か」ではなく「どう決めるか」を書いている記事は少ない。

私は命名で何度も揉めた。レビューで指摘された。チームで割れた。後から後悔した。

この記事は、その経験から「どう決めるか」の判断基準をまとめたもの。

🚀 今すぐ変換 → Case Converter を開く

---

私が命名で揉めた話

揉めた話1：FE/BEで命名を揃えようとした

「フロントとバックエンドで同じ名前を使った方が分かりやすい」と思った。

Pythonのバックエンドは user_name（snake_case）。JavaScriptのフロントエンドも user_name にした。

結果：フロントのコードだけ見ると違和感がある。ESLintが警告を出す。後から camelCase に直した。

言語の慣習に逆らうと、結局直すことになる。

揉めた話2：レビューで「一貫性がない」と指摘された

userId と user_id が混在していた。APIから受け取ったまま使っていた。

「どっちかに揃えてください」と指摘された。揃えた。でも変換処理を書く手間が増えた。

最初から変換層を作っておけばよかった。

揉めた話3：DBのカラム名で camelCase を使った

PostgreSQLで userName というカラムを作った。

PostgreSQLは大文字を小文字に正規化する。userName は username になった。user_name と username が混在して、後から直すのが大変だった。

DBは snake_case 一択。例外はない。

---

私の結論（派閥表明）

領域	私の選択	理由
JS/TS	camelCase	言語の慣習。逆らわない
Python	snake_case	PEP 8。逆らうとリンターに怒られる
DB	snake_case	大文字小文字の問題を避ける
CSS	kebab-case	HTML/CSSの慣習
API境界	変換する	FE/BEで無理に揃えない

「どれが正解か」ではなく「言語・領域の慣習に従う」が正解。

---

迷ったらこれ（早見表）

用途	形式	例
JS/TS 変数・関数	camelCase	userName, getUser
クラス・コンポーネント	PascalCase	UserProfile, Button
Python 変数・関数	snake_case	user_name, get_user
定数・環境変数	UPPER_SNAKE_CASE	API_KEY, MAX_COUNT
CSS クラス	kebab-case	user-profile, btn-primary
DB カラム	snake_case	created_at, user_id
URL パス	kebab-case	/user-profile, /api/get-users

---

この記事で判断がつかない場合

知りたいこと	読むべき記事
FE/BEの変換で揉めた経験がない	フロントエンドとバックエンドの命名規則と変換
DBの命名で事故りたくない	DB設計時のカラム名変換テクニック
Reactコンポーネントの命名	Reactコンポーネントの命名規則
BEMを使うべきか迷っている	CSSクラス名の命名規則とBEM
ツールの使い方を知りたい	Case Converterの使い方

---

結局どうするか

命名規則は「好み」ではなく「設計」。

言語・領域の慣習に従う。FE/BEで無理に揃えない。API境界で変換する。

迷ったら慣習に従う。逆らうと後で直すことになる。