Hoisting verstehen

Was ist Hoisting?

Wenn die Engine eine Funktion oder ein Modul lädt, durchläuft sie zwei logische Phasen: in der Creation Phase scannt sie den gesamten Code und legt für jede Deklaration im Scope einen passenden Eintrag an — Funktions-Body, Variablen-Slot, Class-Binding. Erst danach beginnt die Execution Phase, in der die Anweisungen Zeile für Zeile abgearbeitet werden. Der Effekt aus Sicht des Programmierers: Namen, die weiter unten deklariert sind, sind schon vorher bekannt. Genau dieses Phänomen heißt Hoisting.

Der genaue Charakter dieses „Bekanntseins" hängt von der Deklarations-Form ab. Die MDN unterscheidet vier Hoisting-Verhalten — von „voll nutzbar" (Funktionen) bis „existent, aber Zugriff wirft Fehler" (let, const, class).

gruss(); // funktioniert — function-Hoisting

function gruss() {
    console.log('Hallo!');
}

console.log(zaehler); // undefined — var-Hoisting (mit undefined)
var zaehler = 5;

// console.log(name); // ReferenceError — TDZ
let name = 'Anna';

Hallo!
undefined

Function-Hoisting — vollständig

Eine Function-Declaration (function name() { ... }) wird bei der Creation Phase vollständig gehoisted: Name und Body stehen ab dem ersten Moment im Scope zur Verfügung. Das ist Type-1-Hoisting nach MDN-Klassifikation und das einzige Hoisting, das aus Sicht des Aufrufers tatsächlich „magisch" wirkt.

// Aufruf VOR der Definition
console.log(addiere(2, 3)); // 5

function addiere(a, b) {
    return a + b;
}

// Auch verschachtelte Aufrufe und Rekursion funktionieren
console.log(fakultaet(5)); // 120

function fakultaet(n) {
    return n <= 1 ? 1 : n * fakultaet(n - 1);
}

5
120

Praktisch nutzen viele Codebasen diese Eigenschaft, indem sie die Funktions-Definitionen unten und den Top-Level-Aufruf oben platzieren — ein Stil, den manche bevorzugen, andere verpönen.

var-Hoisting — Slot mit undefined

var-Deklarationen werden in der Creation Phase mit dem Wert undefined initialisiert. Das hat eine wichtige Konsequenz: Lesender Zugriff vor der Zuweisungs-Zeile wirft keinen Fehler, sondern liefert undefined. Ein Verhalten, das mehr Bugs versteckt als es löst.

console.log(typeof x); // 'undefined'
console.log(x);        // undefined — KEIN Fehler

var x = 5;

console.log(x);        // 5

// Mental wird das vom Compiler so umgeschrieben:
// var x;          // Creation Phase: Slot mit undefined
// console.log(x); // Execution Phase: liest aus Slot
// x = 5;          // Zuweisung

undefined
undefined
5

Die berüchtigte Interview-Frage lautet: „Was gibt console.log(x); var x = 5; aus?" — Antwort: undefined, eben wegen des Hoistings.

let/const-Hoisting + Temporal Dead Zone

let und const werden ebenfalls gehoisted — die Engine kennt ihren Namen ab Block-Beginn. Der Unterschied zu var: sie sind in dieser Phase uninitialized, nicht undefined. Jeder Zugriff in der Phase zwischen Block-Start und Deklaration wirft ReferenceError. Dieser Bereich heißt Temporal Dead Zone.

{
    // Block-Start — TDZ beginnt hier
    // console.log(x); // ReferenceError: Cannot access 'x' before initialization
    // typeof x;       // ReferenceError — auch typeof greift in TDZ

    let x = 1;          // TDZ endet — x ist initialisiert
    console.log(x);     // 1
}

Wichtig: die TDZ beginnt am Block-Anfang, nicht erst eine Zeile vor der Deklaration. Eine Variable mit gleichem Namen aus einem äußeren Scope wird im inneren Block durch das let/const „verdunkelt" — sogar in den Zeilen davor.

const x = 'aussen';
{
    // console.log(x); // ReferenceError — innerer x "taintet" den ganzen Block,
                      //                obwohl die Deklaration erst unten kommt
    const x = 'innen';
    console.log(x);   // 'innen'
}

Function-Expression vs. Function-Declaration

Eine Function-Expression — also eine Funktion, die einer Variable per const, let oder var zugewiesen wird — folgt den Hoisting-Regeln der jeweiligen Variable, nicht denen einer normalen Function-Declaration. Das ist eine der häufigsten Verwechslungen bei Anfängern.

// Function-Declaration — voll gehoisted
sagHallo();         // 'Hallo!'
function sagHallo() { console.log('Hallo!'); }

// Function-Expression mit const — TDZ wie const
// sagWelt();       // ReferenceError: Cannot access 'sagWelt' before initialization
const sagWelt = function() { console.log('Welt!'); };
sagWelt();          // 'Welt!'

// Arrow-Function mit const — gleiches Verhalten
// sagBye();        // ReferenceError
const sagBye = () => console.log('Bye!');
sagBye();           // 'Bye!'

Hallo!
Welt!
Bye!

Die Konsequenz: wer Funktionen mit const f = () => ... definiert (modern empfohlene Form), kann sie nicht „vor ihrer Zeile" aufrufen. Das ist meist gewollt — Code wird linear lesbar.

Class-Hoisting — TDZ wie let

Klassen werden ebenfalls gehoisted, fallen aber in dieselbe Kategorie wie let und const: existent ab Block-Beginn, aber in TDZ. Ein Aufruf vor der Class-Zeile wirft ReferenceError.

// const a = new Auto(); // ReferenceError: Cannot access 'Auto' before initialization

class Auto {
    constructor(marke) { this.marke = marke; }
}

const b = new Auto('VW'); // ok
console.log(b.marke);     // 'VW'

Das gilt auch für die Erweiterung anderer Klassen: class Sub extends Super wirft, wenn Super zur Zeile noch in TDZ ist.

Praxis: Engine-Phasen — Creation und Execution

Das mentale Modell, das hinter Hoisting steht, lässt sich gut als zwei Pseudo-Phasen einer Funktion lesen. Nehmen wir folgenden Code:

function demo() {
    console.log(a, b, c);
    var a = 1;
    let b = 2;
    const c = 3;
    inner();
    function inner() { console.log('inner'); }
}

So liest die Engine das beim Aufruf von demo() — zuerst die Creation Phase, dann die Execution Phase:

// === Creation Phase ===
// - var a       : Slot anlegen, mit undefined initialisieren
// - let b       : Slot anlegen, status: uninitialized (TDZ)
// - const c     : Slot anlegen, status: uninitialized (TDZ)
// - function inner : Slot anlegen UND Body zuweisen

// === Execution Phase ===
// console.log(a, b, c)
//    -> a = undefined ok
//    -> b ReferenceError — Funktion bricht hier ab
//
// (Der Rest wird gar nicht erreicht.)

Diese Trennung ist der Schlüssel zum Verstehen aller Hoisting-Effekte. Was in der Creation Phase passiert, bestimmt, was in der Execution Phase erlaubt ist.

Hoisting-Reihenfolge bei Konflikten

Wenn im selben Scope eine Function-Declaration und ein var mit dem gleichen Namen stehen, gewinnt am Ende der Creation Phase die Function — der Slot zeigt auf den Funktions-Body. Während der Execution Phase kann eine var-Zuweisung dann den Slot wieder mit einem anderen Wert überschreiben.

console.log(typeof foo); // 'function' — function gewinnt das Hoisting

var foo = 'eine String';

function foo() { return 42; }

console.log(typeof foo); // 'string' — var-Zuweisung hat überschrieben

function
string

Mit let oder const an dieser Stelle wäre der Code ein SyntaxError beim Parsen — Re-Deklaration verboten. Genau deshalb sind diese modernen Formen einfacher zu durchschauen.

Anti-Patterns durch Hoisting

Hoisting ist die Wurzel mehrerer klassischer Bug-Muster. Drei davon sind besonders verbreitet:

1. var in einem if-Block, der außerhalb des Blocks weiterlebt — ein Klassiker beim Refactoring.
2. Function-Declarations in Blöcken, deren Verhalten zwischen Strict und Sloppy Mode unterschiedlich ist.
3. Variable, die vor der Zeile verwendet wird, an der sie deklariert wird — bei var ein versteckter undefined, bei let ein klarer ReferenceError.

// Anti-Pattern 1: var lebt außerhalb des if-Blocks
function f1() {
    if (true) { var x = 1; }
    console.log(x); // 1 — überraschend
}

// Anti-Pattern 2: function-Declaration in if-Block
// (in strict mode block-scoped, in sloppy mode hochgehoben)
function f2(flag) {
    if (flag) {
        function helper() { return 'ja'; }
    }
    // helper() — Verhalten je nach Modus inkonsistent
}

// Anti-Pattern 3: var-Hoisting verwischt Lesbarkeit
function f3() {
    console.log(name); // undefined — wirkt wie ein Bug
    var name = 'Anna';
}

In modernem Code, der konsequent let/const und ESM nutzt, verschwindet das meiste davon — die Engine zwingt zur sauberen Reihenfolge.

Best Practices

Drei Regeln decken praktisch alle Fälle gut ab:

• Deklarationen am Anfang des Scopes platzieren. Auch wenn Hoisting es technisch erlaubt, weiter unten zu deklarieren — Lesbarkeit gewinnt, wenn die Reihenfolge der physischen Zeilen mit der logischen Reihenfolge übereinstimmt.
• function-Declarations nicht in Blöcken nutzen. Stattdessen eine Variable mit Function-Expression: const helper = () => .... Das vermeidet die Mode-Unterschiede zwischen Strict und Sloppy.
• let/const statt var. Die TDZ macht Hoisting-Bugs zu lauten Fehlern, statt sie als undefined-Werte zu verstecken.

Weiterführende Ressourcen

Externe Quellen

• Hoisting – MDN Glossary
• var – MDN
• let – MDN
• Let and Const Declarations – ECMAScript Spec

Verwandte Artikel

• Variablen: var, let, const
• Function-Declaration vs. Expression
• JavaScript-Engine: Mental Model
• Strict Mode
• Class-Syntax
• Closures