変数の「再宣言」という名の時限爆弾：なぜ我々は `var` を葬り去るべきなのか
フロントエンドの戦場において、我々が直面するバグの多くは、実は言語仕様の「甘さ」に起因している。特に、JavaScript黎明期の遺物である `var` は、現代の大規模なSPA開発において、まるで時限爆弾のような振る舞いをする。
今日は、`var`、`let`、`const` の再宣言ルールを単なる文法としてではなく、ブラウザエンジンのメモリ管理や、実行コンテキストの深淵という観点から解剖していこう。
—
1. `var` が招く「不可視の汚染」と再宣言の罪
`var` を使うな、というのはもはや教条的なスローガンではない。これは、「実行コンテキストの汚染を防ぐ」というアーキテクチャ上の防衛線だ。
`var` は「関数スコープ」を持ち、何よりも同じスコープ内で同じ名前の変数を何度でも再宣言できる。これは一見寛容に見えるが、実際には変数名が重複した瞬間に、古い値が新しい値で静かに上書きされることを意味する。
// 巨大なモジュール内で発生する悪夢
var user = { id: 1 };
// … 500行後、うっかり同じ名前で再宣言
var user = { id: 2 };
console.log(user.id); // 2
// ここで元のデータが消失したことに気づくのは、往々にして本番環境だ。
`var` の再宣言が許される設計は、初期のJSが「小規模なスクリプトを走らせるためだけの言語」だった名残だ。しかし、現代の複雑なコンポーネントツリーや、数万行規模のステート管理において、この仕様は「意図しないグローバル汚染」の温床となる。
2. `let` と `const` が守る「宣言の正当性」
一方、ES6で導入された `let` と `const` は、再宣言を構文レベルで禁止している。これは単なる制限ではない。「その変数が、そのスコープにおいて唯一無二であること」をエンジニアが宣言するという、契約プログラミングに近い設計思想だ。
なぜ再宣言を禁止する必要があるのか？
ブラウザエンジン（V8など）は、変数をメモリに配置する際、スコープごとに「環境レコード（Environment Record）」を作成する。`let` や `const` で再宣言を禁止することで、エンジンは「このスコープにおいて、この識別子は必ずこの場所を指す」と最適化を確信できる。
もし再宣言が許されていれば、コンパイラは実行のたびに「この変数は今のスコープで再定義されているか？」というチェックを走らせなければならない。これはパフォーマンスの微細なロスを生むだけでなく、非同期処理の競合を引き起こす。
// 非同期処理における再宣言の恐怖
let count = 0;
// 非同期で再宣言が許されていたら…
// Promise内で別の count が宣言され、外部と内部で値が乖離するバグが多発する
3. メモリ効率とTDZ（一時的デッドゾーン）
`var` が巻き上げ（Hoisting）によって `undefined` で初期化されるのに対し、`let` や `const` は「一時的デッドゾーン（TDZ）」に置かれる。
{
// console.log(a); // ReferenceError: Cannot access ‘a’ before initialization
let a = 10;
}
この「初期化されるまで触らせない」という姿勢こそが、バグを未然に防ぐアーキテクチャだ。`var` のように「とりあえず値は未定義だけど、変数は存在する」という曖昧な状態を許さない。これにより、コードの宣言順序が論理的に正しく整理され、結果としてV8エンジンが最適化しやすい、クリーンな抽象構文木（AST）が生成される。
4. 実戦的プラクティス：なぜ `const` がデフォルトなのか
上級エンジニアの現場では、「基本は `const`、変更が必要な時だけ `let`、`var` は存在しないものとする」という鉄則が浸透している。
- `const` が提供する最強の最適化:
`const` は「値の再代入不可」を保証する。これにより、エンジニアは「この変数はイミュータブルである」と脳内で断定でき、非同期処理やクロージャ内でのバグのリスクを劇的に下げられる。また、エンジン側も値が不変であることを前提に、メモリアドレスの固定化などの最適化を積極的に行える。
- `let` は「再代入」のためだけに使う:
ループカウンタや、状態遷移のような「値が動く必要がある」箇所に限定する。再宣言は一切行わない。
結論：厳格さは、自由への近道
再宣言が禁止されていることは、制約ではなく「品質保証」だ。
あなたが構築するWebアプリケーションが、数百万人のユーザーに利用されるものであろうと、小規模な社内ツールであろうと、コードの堅牢性は「言語仕様の制約」をいかに味方につけるかで決まる。
`var` を使い続けることは、過去の負債を現代のアプリケーションに持ち込むことに他ならない。もしあなたのプロジェクトで未だに `var` が息づいているなら、それはコードの静的解析ツールを導入し、今すぐ排除するべき「技術的負債」であると断言しよう。
正しいスコープ設計は、アプリケーションのパフォーマンス、メモリ効率、そしてエンジニアの精神的な平穏を支える、最も基本的なアーキテクチャの礎なのだから。
コメント