Zum Hauptinhalt springen

🧹 Linting

Linting ist statische Codeanalyse auf Source-Code-Ebene.
Ein Linter überprüft Code gegen Regeln und meldet Auffälligkeiten bevor der Code ausgeführt wird.

Linting ist kein Selbstzweck.
Es ist ein skalierbarer Mechanismus, um Fehlerklassen zu verhindern, Code konsistent zu halten und Teamarbeit zu entlasten.

1. Ziel und Einordnung​

1.1 Was macht ein Linter?​

Ein Linter analysiert Quellcode und findet:

  • Stil- und Formatabweichungen (z. B. Quotes, Imports, Naming)
  • potenzielle Fehler (z. B. ungenutzte Variablen, unreachable code)
  • riskante Patterns (z. B. fallthrough in switch, lose equality)
  • Architektur-/Modulgrenzen (z. B. unerlaubte Imports)
  • Sicherheits-nahe Basics (z. B. unsichere eval-Nutzung, Secrets-Muster – je nach Regelset)

Linting greift früh: beim Schreiben, im Pre-Commit, in CI.

1.2 Was macht ein Linter nicht?​

Ein Linter ist:

  • kein Compiler (er garantiert keine Typkorrektheit)
  • kein Test (er beweist keine fachliche Richtigkeit)
  • kein Performance-Profiler
  • kein Ersatz für Security Audits
  • kein Ersatz für Code Review

Ein Linter kann Fehlermuster erkennen –
aber keine Geschäftslogik verstehen.

2. Warum Linting wichtig ist​

2.1 Einheitlicher Stil ist kein „Style War“​

Ohne Linting diskutieren Teams endlos über:

  • Semikolons
  • Quotes
  • Import-Order
  • Naming
  • Klammerung / Curly Braces

Mit Linting sind diese Fragen automatisiert.

Der wichtigste Effekt von Stilregeln ist nicht Schönheit, sondern Reibungsreduktion.

Code wird:

  • schneller lesbar
  • konsistenter
  • reviewbar (Diffs werden kleiner, Diskussionen weniger)

2.2 Linting verhindert reale Fehlerklassen​

Viele Regeln wirken „kosmetisch“, verhindern aber bekannte Fehler.

2.3 Curly Braces sind kein Stil – sie sind Sicherheit​

Ein klassischer Fehler entsteht durch fehlende {} bei if-Statements.

Beispiel:

if (isAdmin)
  deleteUser(userId);
  logAuditEvent(userId);

Hier wird logAuditEvent immer ausgeführt – unabhängig von der Bedingung.

Solche Fehler sind visuell schwer zu erkennen und werden im Review oft übersehen.

2.4 Realer Sicherheitsvorfall: „goto fail“​

Apple veröffentlichte 2014 ein Sicherheitsupdate für iOS und macOS, nachdem ein Fehler in der SSL-Implementierung bekannt wurde.

Im Code stand sinngemäß:

if ((err = SSLHashSHA1.update(...)) != 0)
    goto fail;
    goto fail;

Durch die fehlenden geschweiften Klammern gehörte das zweite goto fail; nicht mehr zum if-Block.

Ergebnis:

  • Die Zertifikatsprüfung wurde übersprungen.
  • Man-in-the-Middle-Angriffe waren möglich.
  • Jede HTTPS-Verbindung konnte unter bestimmten Bedingungen kompromittiert werden.

Der Fehler war kein kryptographisches Problem. Er war ein Kontrollflussproblem durch fehlende Klammern.

2.5 Konsequenz für professionelle Teams​

Die ESLint-Regel curly (always) verhindert genau diese Fehlerklasse.

Empfehlung:

  • Erzwinge {} auch bei Einzeilern.
  • Keine Ausnahmen.
  • Kein „aber ist doch kürzer“.

Ein Linter ersetzt kein Code Review – aber er verhindert bekannte, historisch belegte Fehlerklassen.

Curly-Braces sind kein Stilthema. Sie sind eine Schutzmaßnahme gegen Kontrollfluss-Bugs.