【実務・中級編】 letによる変数宣言とブロックスコープ – JavaScript実践ガイド

こんにちは。現場でコードをレビューしていると、未だに `var` が混ざっていたり、かと思えば「とりあえず全部 `const` にして、どうしても変更が必要な時だけ `let` にする」という思考停止に陥っているコードを見かけることがあります。

中級エンジニアの皆さん、`let` の本質を理解することは、単に「`var` との違いを知る」ことではありません。「メモリのライフサイクルを制御し、コードの意図を明示する」という、プロとしての作法そのものなんです。

今日は、なぜ僕たちが `let` を選び、どう使いこなすべきなのか、ブラウザの裏側の挙動を交えて深掘りしていきましょう。

—

まず、なぜ `let` が必要だったのか。最大の理由は「スコープの汚染」です。

`var` は関数スコープであり、ブロックスコープ（`if`文や`for`文の `{}`）を貫通します。これは、現代の複雑なフロントエンドアプリケーションでは、バグの温床でしかありません。

// var の悪夢
if (true) {
var message = “Hello”;
}
console.log(message); // “Hello” が取れてしまう。これ、意図してますか？

一方、`let` はブロックスコープです。`{}` の外からは決してアクセスできません。これは「この変数はこの処理の範囲内でしか生きない」というエンジニアの意図を、JavaScriptのエンジンが強制的に担保してくれることを意味します。

ここで一つ、深い話をしましょう。`let` で宣言された変数は「巻き上げ（hoisting）」が起きない……というのは半分嘘です。正しくは「宣言前にアクセスすると `ReferenceError` になる」という制約が裏側に存在します。

これをTDZ（Temporal Dead Zone：一時的死域）と呼びます。

{
// ここから TDZ が開始
// console.log(user); // ここで参照すると ReferenceError

let user = “Dev”; // ここで変数が初期化され、TDZが終了
console.log(user); // “Dev”
}

ブラウザのJSエンジンは、`let` を見つけると、宣言されるまでの間、その変数に対して「アクセス禁止」のフラグを立てます。これは、未定義の状態で意図せず変数を利用するミスを、実行時に即座に弾くための強力な防波堤です。この挙動のおかげで、コードの信頼性は劇的に向上しました。

現場で読みやすいコードを書くための、僕なりの運用ルールを共有します。

これは基本中の基本ですが、もう一歩踏み込みます。「再代入するかどうか」ではなく、「その変数が指し示す『参照先』が途中で変わる可能性があるか」で判断してください。

// 良い例：カウンタや状態の遷移に使う
let count = 0;
const increment = () => { count++; };

// 悪い例：初期化後に二度と変わらないのに let を使う
let config = { theme: ‘dark’ };
// これなら const にすべき。let は「いつか変わるかもしれない」というシグナル

`var` を使っていた時代、`setTimeout` をループで回すと全インデックスが最終値になってしまうという悪名高いバグがありました。`let` はブロックごとに新しいスコープを作るため、これを見事に解決します。

// 現場でよく使うパターン：イベントリスナーの登録など
for (let i = 0; i < 3; i++) { setTimeout(() => {
console.log(i); // 0, 1, 2 と正しく出力される
}, 1000);
}

結論を言えば、「変数の生存期間（ライフサイクル）を最小化するため」です。

スコープが狭ければ狭いほど、変数の影響範囲は限定され、バグは見つけやすくなり、メモリ効率も良くなります。`let` を使いこなすことは、自分の書いたコードの「責任範囲」を明確にすることと同義です。

次にエディタを開くときは、`let` と打つ前に一瞬だけ考えてみてください。「この変数は、どのブロックまで生きていれば十分か？」と。その小さな問いの積み重ねが、あなたを単なるコーダーから、信頼されるアーキテクトへと変えていくはずです。

現場からは以上です。また次のコードレビューで会いましょう！