ケーススタイルと命名規則の解説
コード、ファイル、URL、見出しに使う名前は、言語や形式によって異なる慣例に従います。このガイドでは、よく使われるケーススタイルとそれぞれの使いどころ、そして略語、数字、見出し、英語以外の文字といった間違えやすい点をまとめます。
よく使われるスタイル
| スタイル | 例 | 作り方 |
|---|---|---|
| camelCase | orderTotal | 最初の単語は小文字、以降の単語は先頭を大文字に、区切りなし |
| PascalCase | OrderTotal | すべての単語の先頭を大文字に、区切りなし |
| snake_case | order_total | 小文字で、単語を _ でつなぐ |
| CONSTANT_CASE | ORDER_TOTAL | 大文字で、単語を _ でつなぐ |
| kebab-case | order-total | 小文字で、単語を - でつなぐ |
| dot.case | order.total | 小文字で、単語を . でつなぐ |
| Title Case | Order Total | 単語をスペースで区切り、それぞれ先頭を大文字に |
| Sentence case | Order total | 最初の単語だけ先頭を大文字に |
camelCase は lower camel case、PascalCase は upper camel case とも呼ばれます。CONSTANT_CASE は screaming snake case とも言います。
言語と形式ごとに求められるスタイル
多くのエコシステムでは昔から慣例が決まっていて、それに従うと、そのエコシステムを知る誰にとってもコードが読みやすくなります。
| 場所 | 一般的な慣例 |
|---|---|
| JavaScript、TypeScript、Java | 変数と関数は camelCase、クラスは PascalCase、固定の定数は CONSTANT_CASE |
| Python(PEP 8) | 関数と変数は snake_case、クラスは PascalCase、定数は CONSTANT_CASE |
| C# | 型、メソッド、公開メンバーは PascalCase、ローカル変数と引数は camelCase |
| Go | PascalCase はパッケージ外に公開し、camelCase は非公開にする |
| Ruby、Rust | メソッドと変数は snake_case、型は PascalCase |
| CSS と HTML | プロパティ、クラス名、data- 属性は kebab-case |
| URL | kebab-case。Google は単語の区切りにアンダースコアよりハイフンを推奨 |
| SQL のテーブルと列 | snake_case。多くのデータベースが引用符なしの名前を一方の大文字・小文字にそろえるため |
| 環境変数 | DATABASE_URL のような CONSTANT_CASE |
| 設定キー | server.port のように入れ子の設定は dot.case |
| JSON API | 決まった規則はない。camelCase が多く snake_case もあるので、使う API に合わせる |
ほとんどのプログラミング言語ではハイフンがマイナス記号と解釈されるため、変数名に kebab-case は使えません。order-total は order から total を引くという意味になります。
略語と数字
慣例がいちばん分かれるのが略語です。略語を大文字のまま残す流儀(userID、parseHTML)と、普通の単語として扱う流儀(userId、parseHtml)があります。Google の Java と JavaScript のスタイルガイドは後者で、略語が続くときも単語の境界がはっきりします。XmlHttpRequest は XMLHTTPRequest より区切りやすいのです。Microsoft の .NET ガイドラインは 2 文字の略語を大文字にし(IOStream)、それより長い略語は先頭だけ大文字にします(HtmlButton)。ブラウザーの API XMLHttpRequest は両方が混ざっていて、悪い例としてよく引き合いに出されます。
数字には大文字・小文字がないので、変換ツールには utf8Decoder が「utf8 decoder」なのか「utf 8 decoder」なのか判断できません。変換ツールは通常、数字を前の単語にくっつけます。表記を 1 つに決めて、どこでも同じように使いましょう。
見出しの Title Case と Sentence case
英語の見出しでは、スタイルガイドによって単語の大文字の付け方が異なります。AP や Chicago のスタイルは、短い冠詞、接続詞、前置詞を最初や最後でない限り小文字にし("The Lord of the Rings")、その具体的な一覧は互いに違います。Microsoft や Google の開発者向けドキュメントのガイドをはじめ、多くの UI・ドキュメントのガイドは代わりに Sentence case("Change your password")を使います。一貫して適用しやすく、堅苦しさも和らぎます。
LeedyBox の変換ツールの Title Case はすべての単語の先頭を大文字にします。ラベルや変数のような名前には合いますが、新聞の見出しスタイルには合わないので、変換後に短い単語を手で小文字に直してください。
スタイル変換で情報が失われる
どの変換も、まず大文字や区切り文字を手がかりに名前を単語に分け、それから新しいスタイルで単語をつなぎます。変換先のスタイルで表せないものは失われます。parseHTML は parse_html になり、元に戻すと parseHtml になります。句読点も落ちるので、"don't" は 2 つの単語になります。
ですから、1 つのスタイルを基準にしましょう。データベースが snake_case でコードが camelCase なら、名前を両方の形で保存するのではなく、境界で毎回同じ向きに変換します。
API の境界でキー名を変える
camelCase のフロントエンドが snake_case のバックエンドとやり取りするとき、多くのシリアライズライブラリは名前を自動で対応づけられるので、データを手で変える必要はありません。テスト用データやサンプルレスポンスのように JSON 文書を一度だけ変換するのは別の作業で、ケース変換の「JSON のキー」モードは値に触れずにそれを行います。
衝突に注意してください。user_name と userName はどちらのスタイルでも同じキーになり、一方がもう一方を上書きします。_id や $ref のように記号で始まるキーは、特定のデータベースやスキーマで意味を持つことが多いので、そもそも名前を変えてよいかを確認してください。
英語以外の大文字と小文字
大文字・小文字の規則は言語によって異なります。ドイツ語の ß は大文字にすると SS になり、単語が長くなります。トルコ語には点のある i と点のない ı があり、大文字の対は i → İ、ı → I ですが、多くのプログラミング言語が使う既定の規則は i を I に変えます。JavaScript の toUpperCase() は既定の規則を、toLocaleUpperCase('tr') はトルコ語の規則を使います。韓国語、中国語、日本語には大文字・小文字がまったくないので、変わるのは単語の間の区切りだけです。
ファイル名でも大文字・小文字が問題になります。Windows と既定設定の macOS は Readme.md と README.md を同じファイルとして扱いますが、Linux は別々の 2 つのファイルとして扱います。そのため、大文字・小文字だけを変えた名前の変更が、あるシステムでは気づかれず、別のシステムでリンクや import を壊すことがあります。
よくある質問
camelCase と snake_case はどちらが良いですか?
一般的にどちらが優れているということはありません。使っている言語、フレームワーク、API の慣例に従ってください。1 つのコードベースの中で一貫していることのほうが、どちらを選ぶかより大切です。
URL にはハイフンとアンダースコアのどちらを使うべきですか?
ハイフンです。Google の URL に関するガイドは単語の区切りにハイフンを推奨しており、/case-converter/ のような kebab-case のスラッグが Web では一般的です。
ファイル名の大文字・小文字だけを変えたのに Git が気づかないのはなぜですか?
大文字・小文字を区別しないファイルシステムでは、Git が古い名前と新しい名前を同じファイルとして扱うことがよくあります。大文字・小文字を区別するシステムにも変更が記録されるよう、たとえば一時的な名前を経由して git mv で名前を変えてください。
iPhone や eBay のようなブランド名は camelCase でどう書けばよいですか?
変換ツールは大文字で単語を分けるため、こうした名前は別々の単語になります。コードではブランドを 1 つの単語として扱うほうが通常わかりやすく(iphoneModel)、正式な表記は人に見せるテキストだけで使いましょう。