====== LU07: Debugging – Fehler finden und verstehen ======

{{:de:modul:m291:learningunits:lu07:theorie:debugging.png?nolink&400| 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.

<WRAP center round tip 80%>
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".
</WRAP>


===== 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:
<WRAP round box 80% center>
^ 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 |
</WRAP>

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:

<WRAP round box 80% center>
^ 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) |
</WRAP>

===== 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 ====

{{:modul:m290_guko:leistungsbeurteilungen:03_lb:webstorm_4x.png?nolink&300| Webstorm Logo}}

WebStorm prüft den Code automatisch im Hintergrund – ohne zusätzliche Extensions. Farbige Unterwellungen bedeuten:
  * **Rot** → Fehler (der Code wird nicht korrekt ausgeführt)
  * **Gelb** → Warnung (sollte behoben werden)
  * **Grau** → Hinweis (Stil-Empfehlung)

{{:de:modul:m291:learningunits:lu07:theorie:screenshot_2026-03-22_at_11.10.17.png?nolink&800| Webstorm Code mit Fehlern. }}
\\
//WebStorm Code mit Fehleranzeige.//

{{:de:modul:m291:learningunits:lu07:theorie:screenshot_2026-03-22_at_11.15.00.png?direct&700| Webstorm Screenshot mit Fehlermeldung. }}
\\
//Fahren Sie mit der Maus über die Markierung – Sie sehen eine Erklärung des Problems.//\\

WebStorm erkennt unter anderem:
  * Fehlende Dateiendungen: ''<link href="style">'' → //Cannot resolve file 'style'//
  * Falsche Anführungszeichen: ''<link href=„style.css">'' → //Cannot resolve file '„style.css"'//
  * Tippfehler in CSS-Eigenschaften: ''heihgt'' → unbekannte Eigenschaft

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

==== VS Code: Prettier + HTMLHint ====

{{:de:modul:m291:learningunits:lu07:theorie:visual-studio-code-4096.png?nolink&200| VS Code Logo}}
{{:de:modul:m291:learningunits:lu07:theorie:prettier-logo.png?nolink&400| Prettier Logo}}
{{:de:modul:m291:learningunits:lu07:theorie:htmlhint.dircoa_t_z1cgbhd.webp?nolink&200 | 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):
  - Extensions-Tab öffnen (Ctrl+Shift+X / Cmd+Shift+X)
  - Suchen: **Prettier – Code formatter**, installieren
  - 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:
  - Suchen: **HTMLHint**, installieren
  - Keine weitere Konfiguration nötig – funktioniert sofort
  - Website mit Dokumentation aller Regeln: [[https://htmlhint.com|htmlhint.com]]

<WRAP center round info 80%>
**Hinweis:** Für CSS gibt es [[https://stylelint.io|Stylelint]] – ein Linter, der ähnlich wie HTMLHint funktioniert, aber für CSS-Dateien.
</WRAP>

==== Typische Fehler, die diese Tools erkennen ====

**Falsche Anführungszeichen** (WebStorm & HTMLHint):

<WRAP round box 80% center>
<code html>
<!-- ❌ 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">
</code>
</WRAP>

<WRAP center round important 80%>
**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).
</WRAP>

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

<WRAP round box 80% center>
<code css>
/* ❌ 'heihgt' statt 'height' – Browser ignoriert diese Zeile einfach, kein Console-Fehler */
.panel.open {
  heihgt: auto;
  opacity: 1;
}

/* ✅ Korrekt */
.panel.open {
  height: auto;
  opacity: 1;
}
</code>

{{:de:modul:m291:learningunits:lu07:theorie:screenshot_2026-03-22_at_15.11.10.png?nolink&800|}}
//Fehlermeldung in VS Code: CSS-Eigenschaft falsch geschrieben.//
</WRAP>

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**.

<WRAP center round tip 80%>
Öffnen Sie die Console, **bevor** Sie anfangen zu raten. Die Fehlermeldung sagt Ihnen meistens genau, was falsch ist – und in welcher Zeile.
</WRAP>

==== Fehlermeldungen lesen ====

{{:de:modul:m291:learningunits:lu07:theorie:screenshot_2026-03-22_at_14.49.40.png?nolink&800| Screenshot mit Fehlermeldung in Entwicklertools}}

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

<WRAP round box 80% center>
^ 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 |
</WRAP>

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".

<WRAP round box 80% center>
<code js>
// ❌ 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);
</code>
</WRAP>


==== Read → Reproduce → Reduce: Ein konkretes Beispiel ====

Hier ein typischer Fehler aus dem Accordion-Projekt:

<WRAP round box 80% center>
<code js>
// ❌ Fehler: 'e' wurde im EventListener nicht deklariert
buttons.forEach((button) => {
  button.addEventListener('click', () => {   // ← 'e' fehlt als Parameter
    const panelElement = e.target.nextElementSibling;
    // ...
  });
});
</code>

{{:de:modul:m291:learningunits:lu07:theorie:screenshot_2026-03-22_at_14.49.40.png?direct&900| 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.target'' – ''e'' ist nirgends definiert
  * **Fix**: Den Parameter ''e'' in der Klammer (e) ergänzen
</WRAP>





<WRAP round box 80% center>
<code js>
// ✅ Korrekt: 'e' als Parameter deklariert
buttons.forEach((button) => {
  button.addEventListener('click', (e) => {  // ← 'e' als Parameter
    const panelElement = e.target.nextElementSibling;
    // ...
  });
});
</code>
</WRAP>

==== 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.
 

<WRAP round box 80% center>
=== Script im <head> - falsch! ===
{{:de:modul:m291:learningunits:lu07:theorie:script_im_head.png?nolink&700| Script im Head}}

<code html>
<!DOCTYPE html>
<html>
<head>
  <script src="script.js"></script>  <!-- zu früh! -->
</head>
<body>
 
</body>
</html>

=== Script vor </body> - gut! ===

{{:de:modul:m291:learningunits:lu07:theorie:script_before_body.png?nolink&700| Script im Body}}

</WRAP>

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.

{{:de:modul:m291:learningunits:lu07:theorie:screenshot_2026-03-22_at_21.53.20.png?nolink&800| Elements-Tab im Browser}}

==== CSS live ausprobieren ====

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

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

<WRAP center round tip 80%>
Deaktivierte CSS-Regeln (durchgestrichen) bedeuten: eine andere Regel mit höherer Spezifität (s. CSS Kaskade LU02) gewinnt oder es gibt ein Syntax-Fehler.
</WRAP>


===== Das Debugging-Protokoll =====

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

<WRAP round box 80% center>
^ 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" |
</WRAP>


===== Zusammenfassung =====

<WRAP round box 80% center>
^ 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 |
</WRAP>