命名規則（ケーススタイル）とは、複数の単語からなる名前で単語の区切りをどう表すかのルールです。userName・UserName・user_name・user-name はどれも同じ意味ですが、見た目も使う場面も異なります。本記事では camelCase / PascalCase / snake_case / SCREAMING_SNAKE_CASE / kebab-case / dot.case の定義と例、言語・文脈ごとの慣習、変換時の単語境界の考え方、一貫性を保つ lint ツール、よくある誤りを正確に整理します。
camelCase、クラス・型は PascalCase、Python の変数・関数は snake_case、定数は SCREAMING_SNAKE_CASE、CSS クラスや URL は kebab-case が基本になります。
1. なぜ命名規則が重要なのか
命名規則は「好みの問題」だけではありません。チームで書くコードでは、名前の付け方が揃っているほど読みやすく、間違いが減ります。たとえば同じファイルの中に userName と user_name が混在していると、「これは別の変数なのか？」と読み手が一瞬迷います。
- 可読性：単語の区切りが一目で分かり、名前の意味を素早く読み取れます。
- 一貫性：同じ種類のものが同じスタイルで書かれていれば、検索や置換、補完が効きやすくなります。
- 動作への影響：CSS クラスや URL、JSON のキーなど、ケースの違いがそのまま別物として扱われる場面があります（多くの環境で大文字小文字は区別されます）。見た目だけの問題では済みません。
- 言語の慣習：言語ごとに「標準的なスタイル」があり、それに従うと外部ライブラリやチームの既存コードと自然に馴染みます。
つまり命名規則は、人間にとっての読みやすさと、機械にとっての正しさの両方に関わります。まずは各ケースの形を正確に押さえましょう。
2. 各ケースの定義と例
主要なケーススタイルを、同じ語（"user profile id" の 3 語）でそろえて比較します。
| ケース | 区切りの表し方 | 例（user profile id） |
|---|---|---|
| camelCase | 先頭は小文字、2 語目以降の頭文字を大文字 | userProfileId |
| PascalCase （UpperCamelCase） | すべての単語の頭文字を大文字（先頭も大文字） | UserProfileId |
| snake_case | すべて小文字、単語をアンダースコアで区切る | user_profile_id |
| SCREAMING_SNAKE_CASE （CONSTANT_CASE） | すべて大文字、単語をアンダースコアで区切る | USER_PROFILE_ID |
| kebab-case | すべて小文字、単語をハイフンで区切る | user-profile-id |
| dot.case | すべて小文字、単語をドットで区切る | user.profile.id |
- camelCase の名前は、ラクダのこぶのように途中の大文字が盛り上がって見えることが名前の由来です。
- PascalCase は camelCase の先頭も大文字にしたもので、UpperCamelCase とも呼びます。
- SCREAMING_SNAKE_CASE は snake_case をすべて大文字にしたもので、定数を表すのによく使われ
CONSTANT_CASEとも呼ばれます。 - kebab-case は串に刺さった具（ケバブ）に見立てた呼び名で、ハイフンつなぎを指します。
ハイフンとアンダースコアは見た目が似ていますが、使える場所が違います。多くのプログラミング言語では、ハイフンは「引き算」の演算子と区別がつかないため識別子には使えません。そのため kebab-case はコード内の変数名ではなく、主に CSS や URL、ファイル名で使われます。
3. 言語・文脈ごとの慣習
同じ「変数名」でも、言語によって標準的なケースは異なります。代表的な慣習をまとめます。
| 言語・文脈 | 変数・関数 | クラス・型 | 定数 |
|---|---|---|---|
| JavaScript / TypeScript | camelCase | PascalCase | SCREAMING_SNAKE_CASE |
| Python（PEP 8） | snake_case | PascalCase | SCREAMING_SNAKE_CASE |
| Java / C# | camelCase * | PascalCase | SCREAMING_SNAKE_CASE ** |
| Go | camelCase（公開は PascalCase） | PascalCase | PascalCase / camelCase |
| Rust | snake_case | PascalCase | SCREAMING_SNAKE_CASE |
* C# はメソッドを PascalCase、ローカル変数を camelCase にするなど細かな違いがあります。** C# の定数は PascalCase が推奨されるなど、規約はチームや公式ガイドにより差があります。迷ったら、その言語の公式スタイルガイド（Python なら PEP 8、Go なら Effective Go など）に従うのが安全です。
コードの外でも文脈ごとの定番があります。
- CSS のクラス名：
kebab-caseが一般的（例：.main-nav）。BEM のような命名手法ではアンダースコアやハイフンを組み合わせて構造を表します。 - URL のパス・ファイル名：
kebab-caseが定番（例：/blog/naming-conventions-case-styles/）。小文字に統一すると大文字小文字の取り違えによる事故を防げます。 - 定数：言語を問わず
SCREAMING_SNAKE_CASEが広く使われます（例：MAX_RETRY_COUNT）。 - 環境変数：シェルの慣習に従い
SCREAMING_SNAKE_CASEが標準です（例：DATABASE_URL・API_KEY）。POSIX シェルでは大文字＋アンダースコアが伝統的で、ハイフンは使えません。 - JSON のキー：API によって
camelCaseとsnake_caseのどちらもあり得ます。一つの API 内で混在させないことが大切です。
4. 変換時の単語境界の考え方
あるケースから別のケースへ変換するとき（ツールや関数で自動変換するとき）に肝になるのが、「どこが単語の区切りか」を正しく決めることです。区切りの捉え方さえ決まれば、あとは区切り文字や大文字小文字を当てはめるだけです。
- snake_case / kebab-case は区切りが明示的です。
_や-の位置がそのまま単語境界になります。 - camelCase / PascalCase は区切りが暗黙的で、小文字から大文字への変わり目を境界とみなすのが基本です。
userProfileならuserとprofileに分かれます。
難しいのは連続する大文字（頭字語）の扱いです。parseHTML や HTTPServer のような名前では、どこで区切るかが流儀によって変わります。
HTTPServer を camelCase にするとき、httpServer とするか hTTPServer とするかで結果が変わります。一般には頭字語も 1 単語として扱い、httpServer・HttpServer のように先頭以外を小文字化する流儀が読みやすく、多くのスタイルガイドが推奨しています。自動変換ツールを使うときは、頭字語をどう扱うかを意識すると意図しない結果を避けられます。
つまり変換の本質は「名前を単語の列に分解し、目的のケースで再結合する」ことです。元のケースを正しく読み取れれば、camelCase ⇄ snake_case ⇄ kebab-case の相互変換は機械的に行えます。
5. 一貫性と lint ツール
命名規則は「決める」よりも「守り続ける」ほうが難しいものです。人手のレビューだけに頼ると見落としが出るため、自動でチェックする lint ツールを導入するのが定石です。
- ESLint（JavaScript / TypeScript）：
camelcaseルールや@typescript-eslint/naming-conventionで、変数は camelCase、型は PascalCase、といった規約を強制できます。 - Pylint / flake8（pep8-naming）（Python）：PEP 8 に沿った命名（関数は snake_case、クラスは PascalCase など）を検査します。
- gofmt / golint・clippy（Go / Rust）：言語標準のスタイルに合わせた整形・警告を行います。
- EditorConfig や CI：保存時の整形やプルリクエスト時の自動チェックに組み込むと、規約違反がマージ前に弾かれます。
ポイントは、規約を文章で書くだけでなく、ツールで機械的に強制することです。そうすれば新しいメンバーが加わっても、レビューで毎回指摘する手間なく一貫性を保てます。
6. よくある誤り
最後に、命名規則まわりでありがちなつまずきを挙げます。
- 言語の慣習を無視する：JavaScript の癖のまま Python で
userNameと書く、など。読み手に「他の言語のコードを移植したのかな」と余計な推測をさせてしまいます。 - 1 つのプロジェクト内でケースが混在する：
user_idとuserIdが同じコードベースに混ざると、検索性が落ち、バグの温床になります。 - 大文字小文字の区別を軽視する：URL やファイル名、JSON キーは 大文字小文字が区別されることが多く、
UserIdとuseridは別物として扱われます。とくに大文字小文字を区別しないファイルシステムで開発し、区別するサーバへデプロイすると動かなくなる事故が起きがちです。 - 識別子にハイフンを使ってしまう：多くの言語で
user-nameは「user 引く name」と解釈され、変数名としては使えません。コード内では snake_case か camelCase を使いましょう。 - 頭字語の表記がばらつく：
userID・userId・useridが混在すると一貫性が崩れます。プロジェクトで 1 つに決め、lint で固定するのが安全です。
どの誤りも根は同じで、「慣習に合わせ、一貫させる」ことを徹底すれば避けられます。迷ったら言語・文脈の定番に従い、ツールで強制しましょう。
Free Tool Case Converter で実際に変換する 入力した文字列を camelCase・PascalCase・snake_case・kebab-case などへブラウザ内で相互変換できます。命名の付け替えやリネームに便利です。よくある質問（FAQ）
camelCase と PascalCase の違いは何ですか？
どちらも単語の区切りを大文字で表すスタイルですが、先頭文字の扱いが異なります。camelCase は先頭を小文字にし、2 語目以降の頭文字だけを大文字にします（例：userName）。PascalCase（UpperCamelCase とも呼びます）は先頭の単語も大文字にします（例：UserName）。多くの言語では camelCase を変数・関数名に、PascalCase をクラス名・型名に使い分けます。
Python ではどのケースが慣習ですか？
Python の公式スタイルガイド PEP 8 では、変数・関数・モジュールには snake_case、クラス名には PascalCase（CapWords）、定数には SCREAMING_SNAKE_CASE を使うのが基本です。JavaScript の camelCase に慣れた人が Python で変数を camelCase にしてしまうのはよくある食い違いなので、プロジェクトの言語に合わせた慣習に従いましょう。
URL でケバブケースがよく使われるのはなぜですか？
URL のパスやファイル名では、単語の区切りにハイフンを使う kebab-case が好まれます。理由はいくつかあります。まず多くのサーバやファイルシステムは大文字・小文字を区別するため、小文字に統一すると事故が減ります。次に、アンダースコアはリンクの下線と重なって見えづらく、検索エンジンも歴史的にハイフンを単語区切りとして扱いやすいとされてきました。読みやすさと安全性の両面から kebab-case が定番になっています。