JavaScriptにおけるvarの現在地：なぜ私たちはvarを捨て、letとconstを選ぶべきなのか
モダンなJavaScript開発において、変数の宣言に「var」を使用することは、もはや技術的負債の第一歩と見なされています。ES6（ECMAScript 2015）の登場から長い年月が経過し、letとconstが標準となった現在でも、レガシーコードの保守や、あるいは基礎理解の不足からvarが散見されることがあります。本稿では、なぜvarが現代の開発において不適切であり、どのような挙動が予期せぬバグを引き起こすのかを、フロントエンド・スペシャリストの視点から徹底的に解説します。
varが抱える致命的な設計上の欠陥
varが抱える最大の問題は、その「スコープの広さ」と「巻き上げ（Hoisting）」の挙動にあります。
第一に、varは「関数スコープ」を持ちます。これは、if文やfor文といったブロック（中括弧で囲まれた範囲）を無視して、その変数が含まれる関数全体、あるいはグローバルスコープまで影響を及ぼすことを意味します。ブロック単位でスコープを制御できないことは、複雑なロジックを記述する際に予期せぬ変数の上書きを招きます。
第二に、「巻き上げ」の挙動です。varで宣言された変数は、コードの実行前にメモリ上に確保され、値はundefinedで初期化されます。そのため、宣言の前に変数にアクセスしてもエラーにならず、undefinedという値が返されます。これは動的型付け言語としての柔軟性という側面もありますが、現代の堅牢なアプリケーション開発においては、デバッグを困難にする「暗黙的な挙動」以外の何物でもありません。
letとconstによる解決とスコープの適正化
ES6で導入されたletとconstは「ブロックスコープ」を採用しています。これらは宣言されたブロック（if、for、関数など）の外側からはアクセスできず、宣言される前にアクセスしようとすると「Temporal Dead Zone（一時的死域）」によりReferenceErrorが発生します。
この挙動は、開発者が「変数は宣言してから使う」という当たり前の原則を強制的に守ることを可能にし、コードの予測可能性を劇的に向上させます。また、constは再代入を禁止するため、変数の意図しない変更を未然に防ぐことができます。フロントエンド開発において、状態管理やデータの不変性を重視する現代のトレンドにおいて、constはデフォルトの選択肢であるべきです。
サンプルコード：varとletの挙動比較
以下のコードは、varを使用した場合の典型的なバグの例と、letを使用してそれがどのように解決されるかを示したものです。
// varの挙動：ブロックスコープを無視する
if (true) {
var x = "Hello, var!";
}
console.log(x); // "Hello, var!" が出力される（期待値はスコープ外のためエラー）
// letの挙動：ブロックスコープを守る
if (true) {
let y = "Hello, let!";
}
// console.log(y); // ReferenceError: y is not defined
// varの巻き上げ問題
console.log(a); // undefined
var a = 10;
// letのTemporal Dead Zone
// console.log(b); // ReferenceError: Cannot access 'b' before initialization
let b = 20;
// forループでのvarの罠
for (var i = 0; i < 3; i++) {
setTimeout(() => console.log("var:", i), 100);
}
// 出力結果: var: 3, var: 3, var: 3
// 全てのコールバックが同じ変数 i を参照しているため
for (let j = 0; j < 3; j++) {
setTimeout(() => console.log("let:", j), 100);
}
// 出力結果: let: 0, let: 1, let: 2
// ループごとに新しいスコープが生成されるため
実務におけるエンジニアリングの指針
実務の現場では、以下の3つのルールを徹底することをお勧めします。
1. 基本的にconstを使用する：再代入が必要な場合のみ、例外的にletを使用します。これにより、コードの意図が明確になります。
2. varは禁止する：ESLintなどの静的解析ツールを導入し、`no-var`ルールを有効にすることで、プロジェクト全体でvarの使用を強制的に排除します。
3. レガシーコードのリファクタリング：既存のプロジェクトでvarが多用されている場合、いきなり全てを書き換えるのはリスクを伴います。しかし、新しく書く機能や修正するロジックにおいては、積極的にlet/constへ移行し、段階的な改善を図るべきです。
特に、ループ処理におけるvarの挙動は、非同期処理（PromiseやsetTimeoutなど）と組み合わせた際に、極めて追跡困難なバグを引き起こします。現代のフロントエンド開発において、非同期処理は避けて通れません。その基盤となる変数宣言が不安定であれば、アプリケーション全体の信頼性は損なわれます。
constを使用する際の注意点：不変性との混同
constを使用する際に注意すべき点として、「constは値の不変性を保証するものではない」という点があります。constで宣言されたオブジェクトや配列のプロパティは変更可能です。
const user = { name: "Alice" };
user.name = "Bob"; // これは成功する
// オブジェクトそのものを変更させたくない場合は Object.freeze を使用する
const config = Object.freeze({ theme: "dark" });
// config.theme = "light"; // 厳格モードではエラーになる
この挙動は、constが「変数への再代入」を禁止するものであり、「メモリ上の値そのものの不変性」を保証するものではないことを理解しておく必要があります。Reactなどの状態管理ライブラリを使用する際は、イミュータブル（不変）な更新を意識することが重要ですが、constはそのための第一歩に過ぎません。
まとめ：モダンなコードベースの構築に向けて
varは、JavaScriptの歴史を語る上で欠かせない存在ですが、現代のフロントエンドエンジニアにとっては「過去の遺物」です。letとconstへの移行は、単なる構文の書き換えではありません。それは「スコープの明確化」「意図の伝達」「バグの予防」という、エンジニアリングにおける本質的な品質向上を意味します。
プロフェッショナルな開発者であるならば、なぜvarが使われていたのかという歴史的背景を理解しつつも、現在のベストプラクティスを常に選択しなければなりません。コードは書かれる時間よりも読まれる時間の方が圧倒的に長く、また、自分以外の誰かがメンテナンスする可能性も常にあります。その際、letとconstを使うことは、未来の自分やチームメンバーに対する「コードの可読性を高める」という最大の配慮となります。
今すぐプロジェクトのESLint設定を確認してください。もし`no-var`ルールが設定されていなければ、今この瞬間が、プロジェクトの品質を一段階引き上げるチャンスです。技術は進化します。その進化に取り残されるのではなく、積極的に取り入れる姿勢こそが、フロントエンド・スペシャリストとしての価値を決定づけるのです。
コメント