多くのフロントエンドエンジニアが学習の初期段階で出会う「Hoisting（巻き上げ）」。しかし、実務においてこの挙動を「知っている」ことと「制御できている」ことの間には、大きな壁があります。今回は、単なる暗記ではない、実務目線でのHoistingの捉え方と回避策を解説します。
Hoistingは「巻き上げ」ではなく「メモリ確保」である
まず誤解を解く必要があります。JavaScriptエンジンがコードを実際に上方に移動させているわけではありません。コンパイルフェーズにおいて、スコープ内の変数や関数の宣言がメモリ上に確保されることが、この現象の正体です。
特にvarによる宣言は、メモリ確保と同時にundefinedで初期化されます。これが、宣言前に参照してもエラーにならず、値がundefinedになるという「直感に反する挙動」の原因です。実務コードでvarが忌避される最大の理由は、この曖昧な挙動がデバッグを困難にするからです。
Temporal Dead Zone（TDZ）を味方につける
ES6で導入されたletやconstも、実はHoistingされています。しかし、これらは「一時的死域（TDZ）」という概念によって保護されています。宣言行に到達する前にアクセスしようとすると、ReferenceErrorがスローされます。
一見すると不便に思えるかもしれませんが、これは「変数は宣言してから使うべき」という原則を強制する強力な安全装置です。実務においては、このエラーを「バグの予兆」として積極的に活用すべきです。TDZを無視するようなコード設計を避け、常にスコープの最上部で変数を宣言する習慣を徹底しましょう。
関数宣言と関数式の決定的な違い
実務で最も注意すべきなのが、関数宣言と関数式の扱いです。
関数宣言は、名前の通り宣言全体がHoistingされるため、定義前でも呼び出しが可能です。これはコードの可読性を高める場面もありますが、依存関係が複雑なモジュールでは、どこで定義されているか追いづらくなるリスクがあります。
一方で、const 変数 = () => { … } のような関数式は、変数の初期化まで呼び出しができません。モダンな開発では、「依存関係を明示的にする」「コードの実行順序を予測しやすくする」という観点から、関数式による定義を推奨します。
実務でのベストプラクティス
最後に、明日からの実装で守るべきルールをまとめます。
1. varは絶対に使わない：スコープの汚染とHoistingの副作用を排除するため、eslint-plugin-no-varを導入しましょう。
2. constをデフォルトにする：再代入の必要がない限り、すべての変数はconstで宣言します。これにより、TDZの恩恵を最大限に受けられます。
3. 宣言はスコープの先頭に：意図しないTDZエラーを避けるため、変数は関数やブロックの冒頭で定義するスタイルを徹底してください。
Hoistingを「JavaScriptの仕様の穴」と捉えるのではなく、「コードの品質を担保するためのルール」と捉え直すことで、より堅牢なアプリケーション開発が可能になります。今日のコードから、宣言のタイミングを意識してみてください。