camelCase と PascalCase の違い：キャメルケースとパスカルケースの使い分け
camelCase（キャメルケース）と PascalCase（パスカルケース）の違いは、最初の 1 文字だけです。camelCase は小文字で始め、2 語目以降の頭文字を大文字にします（userName、parseResponse）。PascalCase は、最初の単語も含めてすべての単語の頭文字を大文字にします（UserName、ResponseParser）。慣例として、PascalCase は型（クラス、インターフェース、列挙型、React コンポーネント）を、camelCase は値や動作（変数、関数、メソッド、プロパティ）を表します。
このたった 1 つの大文字は、見た目以上に多くの情報を伝えています。以下では、それが何を示すのか、単なるマナーではなく強制されているのはどの言語か、そして誰の意見も一致しない部分、つまり略語の扱いについて説明します。
camelCase と PascalCase の早見表
| camelCase | PascalCase | |
|---|---|---|
| 最初の文字 | 小文字 | 大文字 |
| 別名 | lowerCamelCase、mixedCase（PEP 8）、camelCasing（Microsoft） | UpperCamelCase、CapWords（PEP 8）、StudlyCaps（PHP の PSR-1）、PascalCasing（Microsoft） |
| 主な用途 | 変数、関数、メソッド、プロパティ、パラメーター | クラス、インターフェース、型エイリアス、列挙型、コンポーネント |
| 例 | orderCount、sendInvoice() | OrderService、InvoiceStatus |
スタイルガイドを読むときは、用語に注意してください。どちらのスタイルも「camel case」と呼ぶ人は多く、PEP 8 に至っては、PascalCase を指す自身の用語 CapWords の別名として CamelCase を挙げています。ガイドの意味がはっきりしないときは、例を見ましょう。
最初の文字が重要な理由：型と値
この慣例のおかげで、何も調べずにコードを読めます。const invoice = new Invoice(order) なら、Invoice が生成するもので、invoice が返ってきたものだと一目でわかります。TypeScript のシグネチャも同じです。function total(order: Order): Money では、小文字の名前が値で、大文字で始まる名前が型です。
また、1 つの単語で型と値の両方に名前を付けても衝突しません。これはしょっちゅう起こります。user: User、config: Config、request: Request などです。大文字・小文字を区別する言語では、これらは別々の識別子であり、どちらがどちらなのかは大文字が読み手に教えてくれます。
言語が強制する場合
JavaScript、Java、C#、Python では、クラス名の大文字・小文字は慣例にすぎません。class invoice と書くことを妨げるものは何もありません。JavaScript なら、ESLint の new-cap ルールで慣例をチェックに変えられます。このルールは標準で new invoice() を指摘し、さらに Invoice() のように大文字で始まる関数を new なしで呼び出すことも指摘します。これはたいていバグです。いくつかの言語やフレームワークはさらに踏み込んで、このルールを組み込んでいます。
Go：最初の文字が可視性のルール
Go には public や private のキーワードがありません。パッケージレベルの名前、構造体のフィールド、メソッドは、最初の文字が大文字ならエクスポートされ、小文字ならそのパッケージ内でしか使えません。PascalCase と camelCase のどちらにするかで、それを選ぶわけです。
package shapes
import "math"
// Circle is exported, so other packages can use it.
type Circle struct {
Radius float64 // exported field
label string // unexported field
}
// Area is exported.
func Area(c Circle) float64 { return math.Pi * square(c.Radius) }
// square is unexported: only code inside package shapes can call it.
func square(x float64) float64 { return x * x }c := shapes.Circle{Radius: 2}
fmt.Println(shapes.Area(c)) // fine
fmt.Println(shapes.square(2)) // compile error: square is not exportedEffective Go が、エクスポートされないフィールド owner のゲッターは GetOwner ではなく Owner と名付けるべきだとしているのも、これが理由です。大文字であること自体が、外から使える入り口だと示しているからです。
React：コンポーネントは大文字で始める
React のドキュメントははっきり書いています。コンポーネント名は大文字で始めなければ動作しません。JSX は、<section> のような小文字のタグを HTML 要素として、<OrderSummary /> のような大文字で始まるタグを自作のコンポーネントとして扱います。
Ruby：クラス名は定数
Ruby では、大文字で始まる名前はすべて定数で、クラス名は定数でなければなりません。class Invoice は動きますが、class invoice は構文エラーになります（「class/module name must be CONSTANT」）。
言語別の使い分け
- JavaScript と TypeScript：変数、関数、メソッド、プロパティは camelCase。クラス、インターフェース、型エイリアス、列挙型、コンポーネントは PascalCase。
- Java と Kotlin：同じ使い分けに加え、真の定数にはアンダースコアでつないだ大文字を使います（
MAX_RETRIES）。 - C#：ほかの言語よりも PascalCase をずっと多く使います。メソッド、プロパティ、イベント、public フィールド、名前空間、さらには定数まで PascalCase です。camelCase はパラメーターとローカル変数に使い、private フィールドには
_camelCaseを使います。典型的なシグネチャはpublic decimal CalculateTotal(decimal taxRate)のようになります。 - Swift：型とプロトコルは PascalCase、それ以外はすべて camelCase。
- Go：求める可視性に合うほう。
- Python：PascalCase はクラスだけです。関数と変数は snake_case（スネークケース）で、PEP 8 が camelCase を認めているのは、古いコードですでにそれが主流になっている場合だけです。
- PHP（PSR-1）：クラスは PascalCase、メソッドは camelCase。
定数やファイル名などについては、開発者向けの命名規則チートシートをご覧ください。
難しいのは略語
userId と userID、HttpClient と HTTPClient、正しいのはどちらでしょうか。主要なスタイルガイドの答えは、それぞれ異なります。
| ガイド | ルール | 例 |
|---|---|---|
| Google（JavaScript、TypeScript、Java） | 略語を普通の単語として扱う | xmlHttpRequest、customerId、loadHttpUrl |
| Microsoft .NET | 2 文字の略語は両方とも大文字のまま、それより長い略語は最初の文字だけを大文字にする | IOStream、ioStream、HtmlTag |
| Go | 1 つの略語の中で大文字・小文字をそろえる | ServeHTTP、appID、xmlHTTPRequest |
| Swift | 普段大文字で書く略語は、すべて大文字かすべて小文字にする | utf8Bytes、userSMTPServer |
| Rust | 略語を 1 つの単語として扱う | Uuid、Stdin |
| Python（PEP 8） | CapWords では略語全体を大文字にする | HTTPServerError |
| Airbnb JavaScript | すべて大文字かすべて小文字 | SMSContainer、httpRequests |
私たちの考えはこうです。使っている言語のガイドにルールがあるなら、それに従いましょう。標準ライブラリも同僚も、それを前提にしているからです。ルールがないなら、略語を単語として扱います（HttpClient、userId）。2 つの略語が隣り合っても単語の境目がわかりますし（XMLHTTPRequest と XmlHttpRequest を比べてみてください）、ケーススタイル間で自動変換しても名前が崩れません。ブラウザー自身の XMLHttpRequest でさえ、1 つの名前の中で両方の方式が混ざっています。
さらに背景を知りたい場合は、Microsoft の大文字表記規則（capitalization conventions）が、ひとそろいのルールを 1 ページにまとめた良い例です。
camelCase と PascalCase を相互に変換する
単純な名前なら、変換は 1 文字だけです。最初の文字の大文字・小文字を切り替えます。
const toPascal = (s) => s.charAt(0).toUpperCase() + s.slice(1);
const toCamel = (s) => s.charAt(0).toLowerCase() + s.slice(1);
toPascal("orderTotal"); // "OrderTotal"
toCamel("OrderTotal"); // "orderTotal"
toCamel("HTMLParser"); // "hTMLParser" (acronyms need a smarter split)最後の行を見れば、ツールがまず名前を単語に分割する理由がわかります。扱いにくい入力に対して、ConvertCaseHQ の文字ケース変換ツールが出力する結果は次のとおりです。
| 入力 | camelCase | PascalCase |
|---|---|---|
user id | userId | UserId |
XMLHttpRequest | xmlHttpRequest | XmlHttpRequest |
getUserID | getUserId | GetUserId |
IOError | ioError | IoError |
iPhone | iPhone | IPhone |
このツールは既存の大文字の位置で単語を区切り、略語を単語として書くので、結果は Google のルールと一致します。プロジェクトが Go、.NET、PEP 8 の略語ルールに従っているなら、変換後にそうした名前を手で直してください（Go なら getUserId は getUserID になります）。もう 1 つの落とし穴はブランド名です。IPhone がおかしく見えることを知っているアルゴリズムはありません。
やりがちな 2 つのミス
1 つ目は、インスタンスを大文字で始めることです。const Cart = new ShoppingCart() と書くと Cart が 2 つ目のクラスのように見え、次にコードを読む人はその定義を探しに行ってしまいます。2 つ目は、JavaScript で function FormatPrice() のような PascalCase のヘルパー関数を書くことです。コンストラクターや React コンポーネントでない限り、読み手は new か JSX が必要だと考えますし、どちらも使わずに呼び出せば new-cap が警告を出します。
覚えておきたい目安
型、または new で生成するものなら PascalCase、値や動作なら camelCase を使います。略語の扱いは言語のガイドに任せ、残りはリンターに覚えてもらいましょう。定数や private フィールドなど JavaScript 特有の話は、JavaScript の命名ガイドをご覧ください。
