CONSTANT_CASE への変換方法：定数と環境変数の命名
定数ケース（スクリーミングスネークケース）は、語をすべて大文字にして 1 つのアンダースコアでつなぐ表記です。コードの定数、設定キー、環境変数はおおむねこの形を使います。
全大文字と下線が必要になる場面
外部サービスを連携すると、設定項目が一度に十数個届きます。max retry count、request timeout、api base url などです。.env や設定モジュールに入れるとき、キーの形が揃っていないと、半分は大文字、半分は小文字になり、読むたびに綴りを確認することになります。
コード内の定数も同じです。同じモジュールに maxRetries と MAX_TIMEOUT が混在すると統一感が失われます。まとめて 1 つの形に変換し、そのあと用途を確認するほうが、書きながら迷うより速く終わります。
- 環境変数と .env ファイルのキー名
- コードの定数、列挙値、設定の既定値
- HTTP ヘッダー名など大文字が慣習の文字列
- 表記が混在した古い定数名の統一
変換の規則と見落としやすい 2 点
順序は、まず「小文字か数字 + 大文字」の境界で分割し、両端の空白を削り、全体を大文字にし、英数字以外の連続を 1 つのアンダースコアにまとめるという流れです。max retry count、maxRetryCount、max-retry-count はどれも MAX_RETRY_COUNT になります。
数字は独立した要素にならず、隣の語にくっつきます。version2 は VERSION2、max retry 2 は MAX_RETRY_2 です。また、空白の削除は大文字化の前なので、記号で始まる入力では先頭に下線が残ることがあります。.env に貼る前に先頭と末尾を確認してください。
- キャメルの境界は分割される（maxRetryCount → MAX_RETRY_COUNT）
- 連続する区切りは 1 つの下線にまとまる
- 数字は隣の語に続く（version2 → VERSION2）
- 漢字は削除されるため、先に英訳する
- 両端に下線が残っていないか確認する
環境ごとの命名制限
POSIX シェルの変数名は英字、数字、下線で構成し、数字で始められません。2FA_KEY は使えず、TWO_FA_KEY や KEY_2FA にする必要があります。Windows の環境変数名は大文字小文字を区別しません。.env に規格はありませんが、読み込み側は KEY=VALUE として解析します。
ツールはこうした規則を確認しません。長さの検証も、重複キーの検出も、その値が秘密情報かどうかの判断もしません。実際に使う前に、対象環境で printenv や設定読み込みを通し、名前が本当に有効か確かめてください。
- シェルの変数名は数字で始められない
- Windows の環境変数名は大文字小文字を区別しない
- 重複キーや長さの確認は行わない
- デプロイ前に環境で読み取れるか確認する
よくある質問
環境変数名が大文字の慣習になったのはなぜですか？
歴史と可読性の両方が理由です。初期の端末は大文字しか扱えず、その習慣が C 言語のプリプロセッサマクロやシェルの慣習に引き継がれ、設定値と通常の変数を区別しやすくなりました。多くのシステムは大文字を強制しませんが、一目で設定項目だと分かります。
数字はどのように扱われますか？
数字は隣の語にくっつき、下線は自動で入りません。max retry 2 は MAX_RETRY_2、version2 は VERSION2 になります。数字を独立させたい場合は、入力でスペースを入れるか、変換後に下線を足してください。
定数名に長さの制限はありますか？
環境によります。シェルや多くの言語は識別子の長さに上限を設けていませんが、環境変数の総量に制限がある環境もあり、Windows は名前と値それぞれに上限があります。ツールは長さを検証しないため、長い名前は実際の環境で試してください。
関連ツール：定数ケース変換