LU07: Debugging – Fehler finden und verstehen

 Debugging: wie ein Detektiv nach Spuren sucht, müssen auch Entwickler:innen den Fehlern auf die Suche gehen.

Debugging bedeutet, mit dem Browser oder dem Code-Editor zu Spuren des Fehlers nachzuforschen – mit den richtigen Werkzeugen, in der richtigen Reihenfolge.

Ein Fehler, den Sie nicht reproduzieren können, ist schwer zu beheben.
Beschreiben Sie den Fehler zuerst genau – nicht „es funktioniert nicht„, sondern „wenn ich auf den Button klicke, passiert X statt Y“.

Warum Debugging wichtig ist

Viele Anfänger raten, was falsch sein könnte. Debugging ist das Gegenteil: Sie prüfen Fakten.

Eine gute Debugging-Gewohnheit folgt immer dieser Reihenfolge:

Schritt Was Sie tun Beispiel
1. Read Lesen Sie die Fehlermeldung genau. Was steht da wirklich? Welche Zeile wird genannt? ReferenceError: e is not defined (script.js:4)
2. Reproduce Lösen Sie den Fehler bewusst aus. Passiert er immer, oder nur manchmal? Bei welcher Aktion genau? „Fehler erscheint jedes Mal, wenn ich auf einen Button klicke„
3. Reduce Grenzen Sie das Problem ein. Welche Zeile, welche Variable, welches Element ist betroffen? console.log(buttons.length) ergibt 0 → Problem liegt im Selector
4. Fix Ändern Sie eine einzige Sache – nicht mehrere auf einmal. Danach sofort testen: Hat diese Änderung den Fehler behoben? Punkt vor Klassennamen ergänzt → buttons.length ergibt nun 4

Oft passiert beim Debugging gar nichts: keine Fehlermeldung, kein Hinweis. Das macht es schwierig. Deshalb brauchen Sie die richtigen Werkzeuge.

Die Debugging-Reihenfolge

Nicht jedes Werkzeug hilft bei jedem Fehler. Gehen Sie diese Reihenfolge durch:

Schritt Werkzeug Hilft bei
1 Formatter / Linter Syntaxfehler (fehlende Klammern, Tippfehler, falsch geschachteltes HTML)
2 Console Laufzeitfehler (was passiert, während der Code läuft)
3 Elements-Tab Rendering-Fehler (was macht der Browser aus Ihrem CSS/HTML)

Werkzeug 1: Formatter & Linter

Bevor Sie die DevTools öffnen: Schauen Sie in den Code-Editor. Viele Fehler können gefunden werden, bevor der Code überhaupt im Browser läuft.

WebStorm

 Webstorm Logo

WebStorm prüft den Code automatisch im Hintergrund – ohne zusätzliche Extensions. Farbige Unterwellungen bedeuten:

 Webstorm Code mit Fehlern.
WebStorm Code mit Fehleranzeige.

 Webstorm Screenshot mit Fehlermeldung.
Fahren Sie mit der Maus über die Markierung – Sie sehen eine Erklärung des Problems.

WebStorm erkennt unter anderem:

Formatieren

Mit Ctrl+Alt+L (Windows) / Cmd+Alt+L (Mac) formatieren Sie die ganze Datei (alles wird schön ausgerichtet).

VS Code: Prettier + HTMLHint

 VS Code Logo  Prettier Logo  HTMLHint Logo

Für VS Code brauchen Sie zwei separate Extensions, um dasselbe Niveau wie WebStorm zu erreichen:

Prettier formatiert den Code automatisch beim Speichern (Einrückung, Strukturierung):

  1. Extensions-Tab öffnen (Ctrl+Shift+X / Cmd+Shift+X)
  2. Suchen: Prettier – Code formatter, installieren
  3. Settings öffnen (Ctrl+, / Cmd+,), suchen nach format on save, Checkbox aktivieren

Ab jetzt: Ctrl+S / Cmd+S → Code wird automatisch aufgeräumt und eingerückt.

HTMLHint prüft die HTML-Struktur und meldet typische Fehler wie falsche Anführungszeichen:

  1. Suchen: HTMLHint, installieren
  2. Keine weitere Konfiguration nötig – funktioniert sofort
  3. Website mit Dokumentation aller Regeln: htmlhint.com

Hinweis: Für CSS gibt es Stylelint – ein Linter, der ähnlich wie HTMLHint funktioniert, aber für CSS-Dateien.

Typische Fehler, die diese Tools erkennen

Falsche Anführungszeichen (WebStorm & HTMLHint):

<!-- ❌ Typografische Anführungszeichen aus Word oder Moodle – Browser lädt die Datei nicht -->
<link href=style.css" rel=„stylesheet">
 
<!-- ✅ Gerade Anführungszeichen -->
<link href="style.css" rel="stylesheet">

Vorsicht beim Kopieren aus Moodle oder Word: Textverarbeitungsprogramme ersetzen gerade Anführungszeichen () durch typografische („ „). Im Browser-Code führt das zu versteckten Fehlern.
Fügen Sie kopierten Code immer als Plain Text ein: Cmd+Shift+V (Mac) / Ctrl+Shift+V (Windows).

Tippfehler in CSS-Eigenschaften (WebStorm & VS Code):

/* ❌ 'heihgt' statt 'height' – Browser ignoriert diese Zeile einfach, kein Console-Fehler */
.panel.open {
  heihgt: auto;
  opacity: 1;
}
 
/* ✅ Korrekt */
.panel.open {
  height: auto;
  opacity: 1;
}

Fehlermeldung in VS Code: CSS-Eigenschaft falsch geschrieben.

Dieser Fehler ist besonders tückisch: das Accordion-Panel öffnet sich visuell nicht, obwohl das JavaScript korrekt funktioniert. Die Console zeigt keinen Fehler.

Werkzeug 2: Die Browser-Console

Die Console ist der direkte Draht zum laufenden JavaScript-Code. Öffnen Sie sie mit F12 → Console.

Öffnen Sie die Console, bevor Sie anfangen zu raten. Die Fehlermeldung sagt Ihnen meistens genau, was falsch ist – und in welcher Zeile.

Fehlermeldungen lesen

 Screenshot mit Fehlermeldung in Entwicklertools

Fehlermeldungen sehen einschüchternd aus, bedeuten aber meist eines von wenigen Dingen:

Fehlermeldung Bedeutung Häufige Ursache
TypeError: Cannot read properties of null Sie greifen auf ein Element zu, das nicht existiert Falscher Selector oder Script im <head> statt vor </body>
ReferenceError: x is not defined Variable x existiert an dieser Stelle nicht Tippfehler im Variablennamen, e im Callback vergessen
ReferenceError: Cannot access 'x' before initialization Variable wird vor ihrer Deklaration benutzt let / const zu weit unten im Code
addEventListener is not a function Das Objekt ist kein DOM-Element querySelector hat null zurückgegeben

Die Fehlermeldung enthält immer eine Zeilennummer – klicken Sie darauf, um direkt zur betroffenen Stelle zu springen.

console.log() richtig einsetzen

console.log() schreibt Werte in die Console. So sehen Sie, was Ihr Code gerade „denkt“.

// ❌ Wenig hilfreich – was ist das genau?
console.log(buttons);
 
// ✅ Mit Label – sofort lesbar
console.log('buttons:', buttons);
console.log('Anzahl gefundene Buttons:', buttons.length);
 
 
// ✅ Fehler bewusst kennzeichnen (erscheint rot in der Console)
console.error('Kein Element gefunden für Selector:', selector);

Read → Reproduce → Reduce: Ein konkretes Beispiel

Hier ein typischer Fehler aus dem Accordion-Projekt:

// ❌ Fehler: 'e' wurde im EventListener nicht deklariert
buttons.forEach((button) => {
  button.addEventListener('click', () => {   // ← 'e' fehlt als Parameter
    const panelElement = e.target.nextElementSibling;
    // ...
  });
});

 Screenshot mit Fehlermeldung in Entwicklertools

Was passiert:

  • Read: Console zeigt Uncaught ReferenceError: e is not defined
  • Reproduce: Jedes Mal beim Klick auf einen Button
  • Reduce: Das Problem liegt in Zeile mit e.targete ist nirgends definiert
  • Fix: Den Parameter e in der Klammer (e) ergänzen
// ✅ Korrekt: 'e' als Parameter deklariert
buttons.forEach((button) => {
  button.addEventListener('click', (e) => {  // ← 'e' als Parameter
    const panelElement = e.target.nextElementSibling;
    // ...
  });
});

Script-Position: Ein stiller, häufiger Fehler

Wird die Verlinkung zum JavaScript-File im <head> Teil des HTML angegeben, dann wird der JS-Code schon ausgeführt, ohne dass die Elemente im HTML durch den Browser erstellt (geparst) wurden. Das kann dazu führen, dass querySelector() null zurückgibt, obwohl im HTML-Code das Element vorhanden ist.

Script im <head> - falsch!

 Script im Head

<code html> <!DOCTYPE html>

Script vor </body> - gut!

 Script im Body

Wenn document.querySelector(…) null zurückgibt, obwohl das Element im HTML vorhanden ist, ist dies die häufigste Ursache.

Werkzeug 3: Der Elements-Tab

Der Elements-Tab zeigt, was der Browser tatsächlich aus Ihrem Code gemacht hat – nicht was Sie geschrieben haben, sondern was nach dem Parsen und Rendern übrig bleibt.

 Elements-Tab im Browser

CSS live ausprobieren

Workflow:

  1. Elements-Tab öffnen (F12 → Elements)
  2. Rechts: Styles-Panel
  3. Eigenschaft anklicken und Wert ändern
  4. Änderung wird direkt im Browser gerendert und sichtbar

Wenn der Look stimmt: dann erst in die CSS-Datei übertragen.

Deaktivierte CSS-Regeln (durchgestrichen) bedeuten: eine andere Regel mit höherer Spezifität (s. CSS Kaskade LU02) gewinnt oder es gibt ein Syntax-Fehler.

Das Debugging-Protokoll

Dieses Format hilft, strukturiert vorzugehen – und aus Fehlern zu lernen. Füllen Sie es aus, wenn Sie einen Bug gefunden haben:

Schritt Frage Beispiel
1. Beobachten Was passiert genau? „Wenn ich auf Frage 2 klicke, passiert gar nichts“
2. Hypothese Was könnte die Ursache sein? „querySelector findet den Button vielleicht nicht„
3. Testen Wie prüfe ich das? console.log('Buttons:', buttons.length)
4. Fazit Was habe ich gelernt? „buttons.length war 0 – Punkt vor Klassennamen fehlte“

Zusammenfassung

Werkzeug Wann einsetzen
Formatter / Prettier Zuerst immer – Syntaxfehler, Tippfehler in CSS-Eigenschaften, falsche Anführungszeichen
Console Wenn etwas passiert oder nicht passiert – Fehlermeldung lesen, console.log() einsetzen, Variablenwerte prüfen
Elements-Tab Wenn das Layout falsch aussieht – CSS live anpassen, Computed-Tab prüfen