-ケバブ-ケース-ゲーム-

💬 はじめに

ここでは「英単語をつなげて1つの識別子（変数名・関数名など）を作るときの書き方（命名規則）」を紹介します。

ゲームで出てくる文字がケバブケースかどうか、見分けるヒントにしてね！

🐪 キャメルケース（camelCase）

別名：ローワーキャメルケース（lowerCamelCase）
＝最初の単語は小文字で始まり、2単語目以降の先頭を大文字にして単語を区切る。区切りに記号は使わない。
例：camelCase, userName, getElementById
由来：単語の途中が大文字で盛り上がる様子が「ラクダのこぶ」に似ているため。
使用言語：JavaScript, Java, TypeScript, Swift, Kotlin, C# など（主に変数名・関数名）

🐪🐪 アッパーキャメルケース（UpperCamelCase）

別名：パスカルケース（PascalCase）
＝すべての単語の先頭を大文字にし、単語をつなげる。区切りに記号は使わない。
例：CamelCase, UserName, GetElementById
由来：ラクダが頭を高く上げているように見えるため。別名はPascal言語で一般的に使われたことからこの名がある。
使用言語：C#, Java, TypeScript, Swift など（主にクラス名・構造体名・型名）

🐍 スネークケース（snake_case）

別名：ローワースネークケース（lower_snake_case）
＝すべての単語を小文字で書き、単語の区切りにはアンダースコア _ を使う。
例：snake_case, user_name, get_element_by_id
由来：アンダースコアが蛇が這っているように見えるため。
使用言語：Python, Ruby, C, SQL など（主に変数名・関数名）

🐍🐍 アッパースネークケース（UPPER_SNAKE_CASE）

別名：スクリーミングスネークケース（SCREAMING_SNAKE_CASE） / コンスタントケース（CONSTANT_CASE）など
＝すべての単語を大文字で書き、区切りにアンダースコア _ を使う。
例：SNAKE_CASE, USER_NAME, MAX_LENGTH
由来：別名は、すべて大文字で“叫んでいる（screaming）”ように見えるため。
使用言語：C, C++, Python, Rust など（主に定数・グローバル変数）

🥙 ケバブケース（kebab-case）

別名：ローワーケバブケース（lower-kebab-case） / リスプケース（lisp-case） / チェインケース（chain-case）
＝すべての単語を小文字で書き、単語の区切りにハイフン - を使う。
例：kebab-case, user-name, get-element-by-id
由来：単語がハイフンで“串刺し”のようにつながっている様子から。別名は、Lisp系言語でよく使われることに由来。
使用言語：HTML属性, CSSクラス名, URL, CLIコマンドなど

🥙🥙 アッパーケバブケース（Upper-Kebab-Case）

別名：トレインケース（Train-Case）
※ 一般的には「トレインケース」として紹介されることが多い表現です。
＝各単語の先頭を大文字にし、単語の間をハイフン - で区切る。
例：Train-Case, Hello-World, User-Profile
由来：別名は、単語の最初の文字が“頭を出して連なって走る列車”のように見えるため。
使用言語：ほとんど使われないが、一部の文書構造や命名スタイルで見られる。

🇭🇺 ハンガリアン記法（Hungarian Notation）

＝変数名の先頭に、その型や意味・用途を表す短い接頭辞（prefix）を付ける、キャメルケースやスネークケースとは別軸のルール。
＝見た目はキャメルケース風が多いが、本質は接頭辞の付け方にあり、他の記法と組み合わせて使われることもある。
例：strName、nCount、btnSubmit
prefix例：str（文字列）, n（数値）, btn（ボタン要素）, sz（文字列長）
由来：発案者のチャールズ・シモニーがハンガリー出身だったため。
使用言語：C, C++, Visual Basic など

⚪️ ドットケース（dot.case）

＝単語をピリオド . で区切る表記。
例：config.file.name, user.profile.image
由来：見たまんま「ドット（.）で区切る」書き方。
使用場面：ファイル名、設定キー、設定ファイル（JSON・YAML・プロパティ形式）、名前空間など

💬 おわりに

このページで紹介している命名規則は、国内外のいろいろなサイトや資料をもとに、共通点を整理してざっくりまとめたものです。

🚨 サイトや資料や地域によって内容や呼び方が異なる場合もあります。
🚨 一部には、比較的マイナーな呼び方や補足的な表現も含みます。
🚨 「ハンガリアン記法」のように、意味づけを含む命名方法も一緒に紹介しています。一部はわかりやすさを優先して簡略化していますのでご了承ください。

より正確で詳細な情報や用途を知りたい場合は、信頼性の高い資料を参照してください。（下記例）

Wikipedia（英語版）: Naming convention (programming) （信頼性が高いかはさておき）
Google Style Guides （Googleが社内向けに定義したスタイルガイドを外部公開したもの）

よく挙げられる命名規則の主なメリットも以下にまとめておきます。

・コードの意図や役割を読み取りやすくなる

・命名の揺れが減り、検索や置換がしやすくなる

・保守やレビューを進めやすくなる

・バグの混入や見落としを減らしやすくなる

・チーム開発で共通理解を持ちやすくなる

・自動化ツールや補完機能と相性が良くなる

命名規則を少しずつマスターしていきましょう！💪