Linter (Static Analysis)

JavaScript: ESLint. Python: Pylint oder Flake8. Oft direkt in der IDE integriert (rote Kringel). Oder im Build-Prozess (CI/CD): "Wenn der Linter meckert, darfst du nicht deployen." Auto-Fix: Viele Linter können einfache Fehler (Leerzeichen, Semikolons) automatisch reparieren (eslint --fix).

1. AST (Abstract Syntax Tree)

Wie funktioniert ein Linter? Er parst den Code in einen Baum (AST). Eine Linter-Regel ist dann simpler Code, der den Baum durchsucht: "Suche alle IfStatement Nodes. Prüfe, ob sie geschweifte Klammern {} haben. Wenn nein -> Error."

2. Custom Rules

In großen Firmen schreibt man eigene Regeln. Beispiel: "Niemals console.log im Production-Code benutzen." Oder: "Jede Variable, die Geld speichert, muss mit Amount enden."

3. Linter vs. Formatter (Prettier)

• Linter (ESLint): Findet Code-Qualitäts-Probleme ("Unbenutzte Variable", "Endlosschleife").
• Formatter (Prettier): Macht den Code schön (Einrückung, Zeilenumbrüche). Ihm ist die Logik egal. Man nutzt meist beides zusammen.

1. Control Flow Graph (CFG) Analysis

Ein naiver AST-Linter reicht für Syntaxfehler. Aber wie erkennt ein Linter: "Variable x könnte null sein" bevor er anläuft? Moderne Linter (wie ESLints komplexere Rules oder SonarQube) berechnen einen Control Flow Graph. Sie simulieren im RAM fiktive Abzweigungen deines Codes: "Was wäre, wenn das API-Backend einen 500er wirft? Springt der Code in das catch? Da im catch x nicht überschrieben wird und im finally auf x.length zugegriffen wird, werfe ich zur Compile-Zeit eine NullReferenceException Warnung." Diese tiefe semantische Analyse macht den Unterschied zwischen einem simplen Stylisten und echtem Static Application Security Testing (SAST).

2. Taint Analysis (Sicherheit)

Linter sind extrem mächtige Security-Waffen gegen SQL-Injection. Sie verwenden Taint Analysis. Der Linter markiert jede Variable, die vom User von Außen kommt (req.body.id), intern als "Tainted" (Vergiftet). Er verfolgt diese Variable präzise über acht verschachtelte Funktionsaufrufe quer durch drei Dateien. Wird diese rohe Variable ungefiltert ("Un-Sanitized") an die Funktion db.execute(sql) übergeben, schreit der Linter Rot. Wird zuvor eine Filter-Funktion (parseInt()) über die Variable gelegt, verliert sie den "Tainted"-Status und der Code gilt als sicher.

3. Shareable Configs & Monorepo Tooling

In großen Firmen pflegt man nicht in 50 Microservices separat eine .eslintrc Datei. Man erschafft eine eigene npm-Library (z.B. @mycompany/eslint-config-base). In dieser Library definieren die Architect-Owner den global verbindlichen Codestandard (Spaces, Braces, Komplexität). In den 50 Microservices wird im .eslintrc lediglich ein extend: ["@mycompany/base"] deklariert. Verändert der Architekt eine Best-Practice Regel in der zentralen Library, färbt dies beim nächsten npm install schlagartig alle CI-Builds rot, die das neue Pattern verletzen (Enforced Compliance).