大文字のconst？：定数定義のベストプラクティスとJavaScriptにおける意味論
JavaScriptやTypeScriptのコードベースを読み解く際、`const MY_CONSTANT = ‘value’` のように、すべて大文字（スネークケース）で定義された定数を目にすることは珍しくありません。しかし、現代のフロントエンド開発において、すべての定数を大文字で書くべきなのでしょうか？あるいは、それは古い慣習に過ぎないのでしょうか？本記事では、定数命名の歴史的背景から、現代的なプロジェクトにおける最適なアプローチまでを専門的な視点で詳細に解説します。
定数命名の歴史的背景とスネークケースのルーツ
「大文字のスネークケース」という命名規則は、C言語の時代にまで遡ります。C言語のプリプロセッサである `#define` を使用して定義されたマクロは、コンパイル時にテキスト置換される性質を持っていました。これらは通常の変数とは異なり、実行時のスコープを持たず、プログラム全体でグローバルに展開されます。そのため、通常の変数と区別し、かつマクロであることを強調するために、すべて大文字で記述する慣習が生まれました。
この慣習は、JavaやPython、そして初期のJavaScriptへと受け継がれました。特にJavaでは `static final` フィールドに対してこの命名規則が強く推奨されており、多くのエンジニアにとって「定数＝大文字」という図式がプログラミングの常識として定着しました。しかし、JavaScript（およびTypeScript）は、これらの言語とは実行環境や型システム、モジュールシステムが根本的に異なります。
JavaScriptにおけるconstの真の意味
JavaScriptにおける `const` キーワードは、「定数（Constant）」を宣言するためのものではなく、「再代入不可（Immutable Binding）」な変数を宣言するためのものです。ここを誤解しているエンジニアは非常に多いのですが、`const` で宣言されたオブジェクトや配列は、その中身（プロパティや要素）を自由に変更することが可能です。
例えば、以下のコードは完全に有効です。
const CONFIG = {
API_URL: 'https://api.example.com',
TIMEOUT: 5000
};
// 再代入はできないが、中身は変更可能
CONFIG.TIMEOUT = 10000;
この挙動からもわかる通り、JavaScriptの `const` は「値が不変であること」を保証するものではありません。したがって、「大文字で書けば不変である」というJava時代の精神モデルをそのまま持ち込むことは、技術的な整合性を欠くことになります。
現代のフロントエンドにおける定数命名の指針
現代のモダンなフロントエンド開発、特にReactやVue、TypeScriptを用いたプロジェクトでは、以下のような基準で命名を決定するのが一般的かつ推奨されます。
1. 真の定数（プリミティブ値）
文字列、数値、真偽値などのプリミティブな値で、かつプログラム全体を通じて固定されているものについては、大文字のスネークケースを使用することが今でも一般的です。これは、その値が「設定値（Configuration）」や「マジックナンバーの代替」であることを一目で判別させるためです。
2. モジュール内の局所的な定数
特定のファイルやコンポーネント内でのみ使用される定数は、`camelCase` で記述するのが現在の主流です。例えば、コンポーネント内で使用する一時的な設定オブジェクトなどは、大文字にする必要はありません。
3. オブジェクトや配列
`const` で宣言されたオブジェクトは、前述の通り中身が可変です。そのため、大文字で `CONFIG` のように記述すると、開発者が「これは不変のデータだ」と錯覚してしまうリスクがあります。オブジェクトや配列に関しては、キャメルケースを用いることで「これは変更可能なデータ構造である」という意図を明確にするべきです。
サンプルコード：ケース別命名のベストプラクティス
実際のプロジェクトにおいて、どのように命名を使い分けるべきか、具体的なコード例で見ていきましょう。
// 1. グローバルあるいはモジュールトップレベルのプリミティブ定数
// 意味：アプリケーション全体の設定値
export const API_TIMEOUT_MS = 5000;
export const MAX_RETRY_COUNT = 3;
// 2. 変更の可能性がある設定オブジェクト
// 意味：大文字にすると不変であると誤解を招くため、キャメルケースを採用
export const appConfig = {
apiUrl: 'https://api.example.com',
endpoints: {
users: '/users',
posts: '/posts'
}
};
// 3. コンポーネント内の定数
// 意味：ローカルスコープであり、外部に公開されないためキャメルケース
const MyComponent = () => {
const DEFAULT_PAGE_SIZE = 10; // 許容範囲だが、キャメルケースの方がモダン
const animationDuration = 300; // 推奨
return ;
};
実務におけるアドバイス：リンターの活用
命名規則を手動で管理するのは限界があります。チーム開発においては、`ESLint` のプラグインを活用してルールを強制するのが最も効率的です。
`eslint-plugin-naming-convention` などのルールを使用することで、特定のファイルパターンやスコープに応じて命名規則を自動的にチェックできます。例えば、「モジュールトップレベルの定数は大文字を許可するが、関数内の変数はすべてキャメルケースにする」といった制御が可能です。
また、TypeScriptを使用している場合は、`as const` アサーションを積極的に活用してください。これにより、オブジェクトや配列のプロパティを「読み取り専用（readonly）」に固定することができ、真の意味での定数を実現できます。
// as const を使用した真の定数化
const ROUTES = {
HOME: '/',
LOGIN: '/login'
} as const;
// ROUTES.HOME = '/new-home'; // エラー！再代入不可となる
まとめ：形式よりも意図を重視する
「大文字のconst」という慣習は、決して無意味なものではありません。それはコードの可読性を高め、設定値とロジックを区別するための視覚的なシグナルとして機能します。しかし、JavaScriptにおいては `const` が持つ「再代入不可」という意味と、「値の不変性」が必ずしもイコールではないことを理解しておく必要があります。
結論として、以下の3点を意識してください。
1. プリミティブな設定値には、これまで通り大文字のスネークケースを使用して問題ない。
2. オブジェクトや配列には、不変であることを保証する `as const` を併用し、命名はキャメルケースを検討する。
3. 何よりも重要なのは「チーム内での一貫性」である。プロジェクトのスタイルガイドを策定し、リンターでそれを自動化することが、最も品質の高いコードベースを維持する近道である。
エンジニアとして、過去の慣習を盲目的に受け入れるのではなく、その言語が持つ特性と現代の開発環境を照らし合わせ、常に「なぜその命名にするのか」という意図を言語化できるようにしておきましょう。それが、シニアエンジニアとしての品格であり、保守性の高いコードを書くための第一歩です。
コメント