一言で言うと
ケース規約（Case Convention）は、コードやWebアドレスで複数の単語からなる名前を書くための文法ルール。人間とマシンの両方が読みやすいようにするためのお約束事です。
どんな問題を解決するのか
はじめに、スペース（空白）がありました。そしてコンピュータはそれを大嫌いでした。初期のプログラミング言語やファイルシステムには、識別子（変数、関数、ファイルなどに付ける名前）に関するシンプルなルールがありました。それは「スペース禁止」。my variableはエラーになります。my-variableは「my マイナス variable」と解釈されてしまうかもしれません。
この制約によって、プログラマーたちはクリエイティブになることを強いられました。my awesome variable name（僕の最高の変数名）を、猫がキーボードの上を歩いたような見た目にならずに、単一の有効なトークンにどうやって押し込めるか？この課題が、命名規則、すなわち「ケーススタイル」の一族を生み出したのです。
問題は、開発者の流派によって選ぶ解決策が異なったことです。C言語やJavaのコミュニティは、今で言うcamelCaseに傾倒しました。PythonやRubyの一派は、ヘビのようなsnake_caseを好みました。LispやCSS界隈の人々はkebab-caseを採用しました。それはまるでデジタルのバベルの塔でした。もしJavaScript開発者（camelCase）がPythonのAPI（snake_case）を扱わなければならなくなったら、彼らは突然バイリンガルの世界に住むことになり、常にfirstNameとfirst_nameの間で翻訳作業をすることになります。これは単なるスタイルの問題ではなく、バグの直接的な原因になるのです。
同じ問題はWeb上にも存在します。「My Awesome Post!」というタイトルのブログ記事のURLは、単に.../My Awesome Post!にはできません。スペースは%20になり、感嘆符は%21になります。その結果は、醜く、共有しにくく、SEOにも不親切なめちゃくちゃな文字列です。解決策は「スラッグ化（slugification）」— テキストをクリーンアップし、URLセーフな文字列（ほとんどの場合kebab-caseが使われる）にフォーマットするプロセスです。
ケース規約とスラッグ化は、コンピュータが必要とする「正確で途切れのない識別子」と、人間が必要とする「読みやすく説明的な名前」との間の根本的な対立を解決するために存在します。それらは、私たちのコードやURLがカオスに陥るのを防ぐ、普遍的な文法なのです。
内部の仕組み
ケース間の変換は、基本的には2ステップのダンスです。まず文字列を構成要素の単語に分割し、次に新しいルールでそれらを結合し直します。スラッグ化は、それに加えてさらにハードコアなクリーニングのステップがいくつか加わります。
分割の妙技
最初にして最もトリッキーな部分は、識別子を分解することです。コンバーターは単にスペースを探すだけではダメ。いくつかの重要な手がかりから単語の区切りを推測する、探偵のようでなければなりません。
- 大文字:
MyVariableName(PascalCase) やmyVariableName(camelCase) では、大文字のVとNが新しい単語の決定的な手がかりです。アルゴリズムは各大文字の前で文字列を分割します。 - 区切り文字:
my_variable_name(snake_case) やmy-variable-name(kebab-case) では、アンダースコア (_) とハイフン (-) が明確な区切り文字です。アルゴリズムは単純にこれらの文字で文字列を分割します。 - すべて大文字:
MY_CONSTANTやHTTPRequestはどうでしょう？ロジックはより複雑になります。MY_CONSTANTの場合、アンダースコアで分割します。HTTPRequestの場合、賢いコンバーターはHTTPを一つの頭字語として認識し、Requestから分割します。単純なコンバーターだとhTTPRequestのような、もう…間違ってるとしか言えない結果になるかもしれません。
というわけで、最初のステップは入力を ['my', 'variable', 'name'] のような単語の配列（array）にトークン化することです。
ケーススタイルの定義
単語の配列ができたら、それらを再構成するのはレシピに従うだけの簡単な作業です。各ケーススタイルには、大文字化と結合に関する独自のシンプルなレシピがあります。
| スタイル | 例 | 大文字/小文字の使い方 | 区切り文字 | 主な用途 |
|---|---|---|---|---|
| camelCase | myVariableName |
最初の単語は小文字、残りは大文字 | (なし) | JavaScriptの変数、JSONキー |
| PascalCase | MyVariableName |
全ての単語の先頭を大文字 | (なし) | クラス名、Reactコンポーネント |
| snake_case | my_variable_name |
全て小文字 | _ (アンダースコア) |
Python, Ruby, PHPの変数; SQLのカラム |
| CONSTANT_CASE | MY_VARIABLE_NAME |
全て大文字 | _ (アンダースコア) |
定数、環境変数 |
| kebab-case | my-variable-name |
全て小文字 | - (ハイフン) |
URLスラッグ、CSSプロパティ、HTML属性 |
| Title Case | My Variable Name |
全ての単語の先頭を大文字 | (スペース) |
人間が読むためのタイトル |
| Sentence case | My variable name |
最初の単語の先頭のみ大文字 | (スペース) |
人間が読むための文章 |
my_variable_name を camelCase に変換するプロセスは次のようになります。
_で分割 ->['my', 'variable', 'name']- 全ての単語を小文字にする ->
['my', 'variable', 'name'](変化なし) - 最初の単語以外の全ての単語の最初の文字を大文字にする ->
['my', 'Variable', 'Name'] - 区切り文字なしで結合 ->
"myVariableName"
識別子からスラッグへ：「スラッグ化」のプロセス
スラッグ化は、ケース変換のタフな兄貴分のようなものです。単に再フォーマットするだけでなく、テキストをサニタイズし、クリーンアップし、URLフレンドリーな形式にローラーで平らにします。
文字列 "C'est l'été! My 2024 recap & thoughts?" をスラッグ化してみましょう。
翻字（Transliteration）: まず、標準的でない文字を最も近いASCIIの同等文字に変換します。これはWebの互換性にとって非常に重要です。
"C'est l'été! My 2024 recap & thoughts?"->"C'est l'ete! My 2024 recap & thoughts?"
小文字化: 文字列全体を小文字に変換します。
"c'est l'ete! my 2024 recap & thoughts?"
区切り文字の置換: スペースやその他の区切り文字になりえそうなものをハイフンに置き換えます。
"c'est-l'ete!-my-2024-recap-&-thoughts?"
文字の削除: 小文字のアルファベット、数字、またはハイフン以外の文字を情け容赦なく取り除きます。
"cest-lete-my-2024-recap--thoughts"
後片付け: 最後に、連続するハイフンを一つにまとめ、先頭または末尾のハイフンを削除して整えます。
"cest-lete-my-2024-recap-thoughts"
最終的なスラッグは、クリーンで読みやすく、100%Webセーフです。
実話から学ぶ
JSONジャングルジム
ある若手フロントエンド開発者が、ユーザープロフィールページを構築するタスクを任されました。Pythonで書かれたバックエンドは、{ "user_id": 42, "full_name": "Brenda", "last_login_at": "2023-10-26T10:00:00Z" } というきれいなJSONオブジェクトを送ってきました。フロントエンドのコードであるReactアプリは、コンポーネントのプロパティとしてcamelCaseを期待していました。開発者は<Profile name={user.fullName} />と書き、名前フィールドが空のまま2時間も画面を眺め、自分の人生の選択を疑い始めました。バグの原因は？user.fullNameがundefinedだったのです。データはそこにあったのに、full_nameというキーの下に。開発者はすべてのフィールドを手動でマッピングする羽目になり、それは退屈でエラーの温床となるプロセスでした。
教訓： 技術スタックの異なる部分（バックエンド/フロントエンド、データベース/API）間でのケースの不一致は、後から考えれば単純でも、追跡するのが非常に腹立たしいバグの一般的な原因です。常にデータの「訛り」を確認しましょう。
SEOスラッグ大失敗
あるライフスタイルブロガーが、真新しいウェブサイトを立ち上げました。最初の投稿「My 5 Favorite Cafés (in Paris!)」が公開されました。URLは.../posts/My%205%20Favorite%20Caf%C3%A9s%20(in%20Paris!)というとんでもない代物でした。読むこともできず、SNSで共有するのも一苦労で、検索エンジンからは疑いの目で見られました。彼女が雇ったSEOコンサルタントは一目見て顔をしかめました。彼らはシンプルなスラッグ化関数を実装しました。新しいURLは.../posts/my-5-favorite-cafes-in-parisとなりました。それはクリーンで、説明的で、すぐにランキングが向上し始めました。
教訓： クリーンで説明的な、kebab-caseのスラッグは、現代のWeb開発において譲れない必須要素です。それらはユーザーエクスペリエンスと検索エンジン最適化の両方の基礎となる要素です。
定数が招いた大惨事
あるチームが、大規模なNode.jsアプリケーションを引き継ぎました。設定はめちゃくちゃ。env.jsという一つのファイルは、5年間にわたって十数人の異なる開発者が書き足した定数のゴミ捨て場でした。そこにはapiKey (camelCase)、DATABASE_URL (CONSTANT_CASE)、そしてEnable-Caching (Pascal-Kebab-Case、真のホラー) が混在していました。開発者が設定値を使うたびに、その場しのぎで決められた特定のケースを調べに行かなければなりませんでした。それは生産性の大幅な低下につながっていました。「品質向上週間」に、彼らはすべての機能開発を止め、一日を費やして設定全体をCONSTANT_CASEにリファクタリングし、自動リンターで強制するようにしました。
教訓： 定数や変数といった特定のコンテキストに対して、単一で一貫したケーススタイルを確立し、徹底しましょう。一度きりのリファクタリングの労力は、認知負荷の軽減とバグの減少という形で、その10倍もの見返りをもたらします。
よくある間違いと落とし穴
- 同じファイル内でケースを混ぜる。 ある行で
let user_idを使い、次の行でlet userNameを使うのは、コードを2つの言語で同時に書いているようなものです。混乱を招く元凶であり、コードレビューでの重大な危険信号です。 - フレームワーク/言語の慣習を無視する。 JavaScriptで
snake_caseの変数名を書くこと（あるいはPythonでcamelCaseを使うこと）は技術的には可能ですが、「最小驚きの原則」に違反します。そのエコシステムにいる他の人にとって、あなたのコードを読みにくく、メンテナンスしにくくします。 - 頭字語の扱いを間違える。
URLやHTTPのような頭字語をどう扱うかは、よくある議論のポイントです。parseUrlとparseURLのどちらにすべきか？ほとんどの現代的なリンターやスタイルガイドは、頭字語を通常の単語のように扱うこと（parseUrl,HttpRequest）を推奨しています。というのも、jsonHTTPRequestは読みにくくなるからです。一貫性を保ちましょう。 - ユーザー生成コンテンツのスラッグ化を忘れる。 ユーザーにカスタムタイトルでページや投稿、プロフィールを作成させる場合、その生のタイトルを絶対にURLに使用してはいけません。それはセキュリティリスクであり、壊れた醜いリンクにつながります。常に最初にスラッグ化プロセスを通しましょう。
- 「フランケンケース」を作り出す。
My_Variable-nameのような独自のスタイルを発明しないでください。何の得もなく、後であなたのコードを読むことになる自分自身や他の人を混乱させるだけです。確立された慣習に従いましょう。
なぜこれが重要なのか
ケーシングについて考えるのは、細かいことを気にする人たちだけのためではありません。それは、クリーンでプロフェッショナルなコードを書くための基本的な側面です。
- 新しいプロジェクトを始めるとき： アプリケーションコードを一行も書く前に、チームはケーシングの規約について合意すべきです。リンター（JavaScriptならESLint、PythonならBlackなど）を設定して、それらを自動的に強制するようにしましょう。これは10分で決められることで、何百時間もの節約につながります。
- APIを構築または利用するとき： JSON（またはXML）ペイロードのケーススタイルは、APIの契約の核となる部分です。もしあなたのAPIが
snake_caseのキーを提供しているなら、クライアントはそれらを使わなければなりません。もしそれらをcamelCaseに変更したら、あなたは重大な破壊的変更を導入したことになります。 - ユニークなアドレスを持つWebコンテンツを作成するとき： URLがあるものには、スラッグが必要です。ブログの投稿、製品ページ、ユーザープロフィール、カテゴリ、そのすべてです。これはあなたのコンテンツ管理システムにおいて、譲れない部分であるべきです。
- データが境界を越えるとき： JavaScriptのフロントエンドがRubyのバックエンドと通信するとき、あるいはC#のアプリがPostgreSQLのデータベースから読み込むとき、あなたはケース規約の国境を越えています。手動で、あるいは変換を自動的に処理するライブラリを使って、翻訳する準備をしておきましょう。
さらに深く
- Wikipedia: Naming convention (programming) - 様々な規約とその歴史に関する決定版の概説。（英語）
- Google JSON Style Guide - JSONのプロパティ名に
camelCaseを推奨する、広く評価されているガイド。（英語） - IETF RFC 3986: URI Generic Syntax - URLで許可される文字とされない文字を定義する技術仕様書で、スラッグ化の基礎を形成しています。（英語）
- MDN Glossary: kebab-case - Mozilla Developer Networkによる簡単な定義で、CSSとHTMLでの使用に焦点を当てています。（英語）
- Airbnb JavaScript Style Guide - JavaScriptにおける命名規則に関する具体的なルールを持つ、人気があり影響力の大きいスタイルガイド。（英語）