T2-Lab

命名規則一覧

Date :
Categories : Tech
Tags : # チートシート # 命名規則

命名は“単なるフォーマット”ではなく、ドメイン知識・歴史的経緯・ツール制約の交差点です。運用するコードベースやプロセスにフィットするものを適切に選んでください。

キャメルケース（camelCase）

camelCase
syndualityEchoOfAda

別名：ローワーキャメルケース

  • 先頭の単語は 小文字
  • 先頭以外の各単語の頭文字は 大文字
観点内容
Pros- 単語境界が視覚的にわかりやすく、読点（ _ や - ）を挟まないのでタイプ数が減る
- Java / JavaScript / C# など主要言語でのローカル変数・メソッド名のデファクト標準
- JSON キーに採用する API が多く、フロント・バックエンド間で相互運用しやすい
Cons- 単語数が増えると“大文字・小文字のどこで区切るか”の認知負荷が高い
- 自動補完・検索で大文字小文字を区別するツールだとヒット率が落ちる
- 先頭が小文字なので「クラス名とインスタンス名を並べた時に見分けにくい」ことも
主な使用シーン- Java / Kotlin / C#：メソッド名・変数名
- JavaScript / TypeScript：変数・関数名、React のフック名
- JSON キー、GraphQL フィールド
避けた方がよいシーン- SQL・NoSQL の列名（snake_case 推奨が多い）
- 定数（UPPER_SNAKE_CASE が一般的）
- URL やファイルシステムでのファイル名（プラットフォーム依存で大文字小文字センシティブ問題）

パスカルケース（PascalCase）

PascalCase
SyndualityEchoOfAda

別名：アッパーキャメルケース

  • 各単語の頭文字は 大文字
観点内容
Pros- 単語の先頭はすべて大文字で視認性が高い
- クラス・型・構造体・列挙型など「シンボリックな識別子」を直感的に区別できる
- .NET / Go（エクスポート識別子）などで“公開/非公開”を大文字で示すことと親和性が高い
Cons- キー入力時にシフト押下が頻発
- 先頭大文字のため、URL のクエリパラメータや JSON キーにそのまま流用すると Web 界隈の慣習から外れる
主な使用シーン- C# / Java：クラス・インターフェイス・列挙型名
- Python：クラス名（PEP 8）
- Go：エクスポート識別子（大文字開始=公開）
避けた方がよいシーン- ローカル変数、プライベート関数（camelCase 推奨の言語が大半）
- HTML / CSS の class / id 名（kebab-case が通例）

スネークケース（snake_case）

snake_case
synduality_echo_of_ada

別名：ローワースネークケース

  • 各単語はすべて 小文字
  • 各単語を アンダースコア _ で繋ぐ
観点内容
Pros- スペースの代わりに _ を入れるだけで視認性抜群かつタイプも楽
- C 言語系ヘッダー、Ruby、Python、Rust など多岐にわたる言語で標準スタイル
- OS や URL での大文字小文字問題を回避できる
Cons- 単語境界が記号のため、長い識別子ではアンダースコアが散らばり可読性が落ちることも
- JavaScript でのローカル変数に使うとチーム毎の規約相違でコンバートコスト
主な使用シーン- Python：モジュール・変数・関数名（PEP 8）
- Rust：関数・変数・ファイル名（Rustfmt）
- SQL カラム / テーブル名、Terraform のリソース名
避けた方がよいシーン- DOM の data-* 属性（kebab-case 前提）
- Windows 環境で ADA プログラム書く際、長い識別子と _ の組み合わせで 260 文字制限に引っ掛かる場合

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

UPPER_SNAKE_CASE
SYNDUALITY_ECHO_OF_ADA

別名：コンスタントケース, スクリーミングスネークケース

  • 各単語はすべて 大文字
  • 各単語を アンダースコア _ で繋ぐ
観点内容
Pros- “定数”であることを一目で示せるためコンテキストスイッチを減らす
- IDE のハイライトや Linters で自動検知できるケースが多く、安全性向上
- C/C++ のマクロ名や .env の環境変数で慣習的に確立
Cons- 文章のように読めず“叫んでいる”印象、行末まで連続すると視認性が下がる
- Switch / if の case ラベルに使うと全体が大文字で冗長に
主な使用シーン- C / C++：マクロ、列挙体定数
- Java：static final 定数
- .env や Docker Secrets の環境変数
避けた方がよいシーン- データベース列名（全大文字列名は RDB により引用符必須のケース）
- HTTP / JSON ペイロード（冗長でワイヤサイズが増える）

ケバブケース（kebab-case）

kebab-case
synduality-echo-of-ada

別名：ローワーケバブケース

  • 各単語はすべて 小文字
  • 各単語を ハイフン - で繋ぐ
観点内容
Pros- URL パス・スラッグにそのまま使えて SEO 上も有利
- HTML / CSS の class / id によく合う（Tailwind CSS など）
- ハイフンが単語区切りで視覚的に自然
Cons- C、Java、Python の識別子には使えない（ハイフンが減算演算子扱い）
- Camel ↔ Kebab の相互変換が実装依存で面倒（大文字情報が失われる）
主な使用シーン- HTML class / id、BEM 命名、CSS 変数
- RESTful API のエンドポイント、Next.js のファイルルーティング
- npm パッケージ名、GitHub リポジトリ名
避けた方がよいシーン- プログラミング言語の識別子（構文エラー）
- Windows コマンドプロンプト（ - をスイッチと誤認される可能性）

トレインケース（Train-Case）

Train-Case
Synduality-Echo-Of-Ada

別名：アッパーケバブケース

  • 各単語はすべて 大文字
  • 各単語を ハイフン - で繋ぐ
観点内容
Pros- HTTP ヘッダ（ Content-Type など）と同形で文脈を想起しやすい
- CLI のサブコマンドや長いオプションでも強調が効く
Cons- 大文字＋ハイフンでキー入力コストが高い
- URL スラッグに使うと SEO 的には大文字が混じり非推奨
主な使用シーン- HTTP / 2 以降でも歴史的に残る一部ヘッダ名
- Markdown の章タイトルをそのままファイル名にする場合
避けた方がよいシーン- JSON キー、HTML 属性（kebab または camel 派が大半）
- Windows や macOS の大小文字非区別 FS でファイル名の衝突が起きやすい

ドットケース（dot.case）

dot.case
synduality.echo.of.ada

別名：ピリオドケース

  • 各単語はすべて 小文字
  • 各単語を ドット . で繋ぐ
観点内容
Pros- パッケージ名や名前空間に使うと階層イメージが明瞭（Java の逆ドメインなど）
- UNIX 隠しファイル（.gitignore）との視覚的一貫性
Cons- 多くの OS やツールで末尾のドットや連続ピリオドに制約があり扱い注意
- URL のパス要素に含めると誤って拡張子解釈されることがある
主な使用シーン- Java / Kotlin：パッケージ名（com.example.app）
- MongoDB コレクションの階層ラベル
- INI・Properties ファイルのキー (spring.datasource.url)
避けた方がよいシーン- POSIX シェル変数（. は演算子扱い）
- Windows のレジストリキー（HKLM…）に混在させると誤読誘発