`var`という「遺物」が抱える罪と、現代のJSアーキテクチャにおける処方箋
フロントエンドの最前線でコードを読み解いていると、たまに心臓が止まりそうになる瞬間がある。数万行のレガシーなSPA、あるいは急ごしらえのライブラリの深淵で、平然と顔を出す`var`キーワードだ。
「`var`は単なる古い書き方でしょう？」と侮ってはいけない。あれは、JavaScriptのメモリ管理や実行コンテキストの理解を放棄した者が招く、静かなる爆弾だ。今日は、なぜ現代の堅牢なアプリケーションにおいて`var`を追放すべきなのか、そしてその「関数スコープ」という仕様が、いかにして高度な非同期処理を崩壊させるのかを、エンジニアの視点で解剖していこう。
1. 「関数スコープ」という名の境界線
`var`の最大の問題は、ブロックを無視する「関数スコープ」にある。ES6以降の`let`や`const`が提供する「ブロックスコープ」は、メモリ効率の観点からも、論理的な意味付けの観点からも、プログラムを小さく、閉じたユニットとして管理するための必須機能だ。
function processData(items) {
for (var i = 0; i < items.length; i++) {
// 巨大なデータセットを扱うループ
var cache = items[i];
// この変数 'cache' は、ループを抜けても関数内であれば生存し続ける
}
// ここで i や cache にアクセスできてしまう
// 意図しないメモリの保持や、後続処理への予期せぬ値の流出（リーク）を招く
console.log(i); // 5 が出力される。これはバグの温床だ
}
この挙動は、V8などのブラウザエンジンにとっても不親切だ。スコープが広ければ広いほど、ガベージコレクション（GC）は「この変数はまだ必要かもしれない」と判断せざるを得ず、不要なメモリが解放されずに長期間スタックに留まることになる。
2. 「巻き上げ（Hoisting）」と非同期の競合
多くの初心者は「`var`は巻き上げられる」という知識で止まっている。だが、真に恐ろしいのは、非同期処理との組み合わせで発生するクロージャの罠だ。
for (var i = 0; i < 3; i++) { setTimeout(function() { // 期待値: 0, 1, 2 // 現実: 3, 3, 3 が出力される console.log("現在のインデックス:", i); }, 100); } なぜこうなるか？ `var`で宣言された`i`は関数スコープを持ち、`setTimeout`のコールバックが実行される頃には、ループを終えた`i`の最終値である`3`がメモリ上に固定されているからだ。 これを解決するために昔のエンジニアは即時実行関数（IIFE）でスコープを強制的に切り出していたが、現代において、言語仕様レベルで解決されている問題をわざわざ手動で回避するのは、技術的な負債以外の何物でもない。
3. 再宣言という名の「事故」
`var`は同じ名前の変数を何度でも宣言できる。大規模なチーム開発において、これがどれほどの破壊力を持つか想像してみてほしい。
var config = { theme: ‘dark’ };
// 数百行後、全く別のモジュールやコンテキストで…
var config = { theme: ‘light’ };
// 前の状態が上書きされ、アプリケーションの整合性が崩壊する
// 実行時エラーを吐かずに「静かに」バグるのが一番タチが悪い
`const`や`let`であれば、再宣言は即座に`SyntaxError`として検知される。静的解析ツール（ESLint）が普及した今、コンパイル時（またはビルド時）にミスを弾けないコードを書くことは、プロフェッショナルとして避けなければならない。
4. 堅牢なアーキテクチャのための鉄則
私たちが目指すべきは、メモリ効率が最適化され、予測可能性の高いコードだ。そのために以下の原則を叩き込んでほしい。
1. `var`をコードベースから永久追放せよ: ESLintの`no-var`ルールを「error」レベルで強制する。これは単なる規約ではなく、メモリ管理とスコープ汚染を防ぐための最低限の防波堤だ。
2. デフォルトは`const`: 変数の再代入が必要な場合のみ`let`を使う。これにより、「この値は途中で変わるはずがない」という認知負荷を低減できる。
3. スコープを最小化せよ: 関数の中であっても、ブロックの直前で宣言する。これにより、ブラウザのエンジンは変数が不要になったタイミングを正確に推測し、GCの効率を最大化できる。
結び：技術の進化を味方につける
かつて`var`が担っていた役割は、現代のJavaScriptエンジン（V8, SpiderMonkey等）の最適化技術と、`let`/`const`という堅牢なツールによって完全に代替された。
「昔からこう書いていたから」という理由は、新しい技術スタックを構築する上では足枷でしかない。深い場所で何が起きているのかを知り、ブラウザが喜ぶような、美しく、メモリ効率の良いコードを書く。それこそが、伝説的なフロントエンド・エンジニアへの唯一の道だ。
さあ、エディタを開いて、あなたのプロジェクトにある全ての`var`にサヨナラを告げよう。それが、あなたのアプリケーションが次に進化するための最初の一歩だ。
コメント