Linter, Formatter und Codequalitätswerkzeuge

In L5 hast du Code-Smells kennengelernt – Stellen, an denen Code stinkt. Die Erkennung von Hand ist mühsam und unzuverlässig. Genau hier kommen Linter und Formatter ins Spiel: automatisierte Werkzeuge, die deinen Code analysieren und Qualitätsprobleme aufzeigen oder direkt korrigieren.

Du lernst hier den Unterschied zwischen Linting (Logik-Probleme finden) und Formatting (Layout korrigieren). Konkrete Werkzeuge je Sprache: ESLint + Prettier für JS/TS, Pylint + Black für Python, Checkstyle + Spotless für Java. Pre-Commit-Hooks und Editor-Integration runden das Bild ab.

1) Linter vs. Formatter – zwei verschiedene Welten

Die beiden Tool-Arten werden oft verwechselt. Sie ergänzen sich, lösen aber unterschiedliche Probleme:

Linter und Formatter im Vergleich

Linter

Sucht Logik-Probleme und Anti-Patterns.

Beispiele: unbenutzte Variablen, unerreichbarer Code, Magic Numbers, Sicherheitslücken.

Konfigurierbare Regelwerke.

Warnt, kann oft auto-fixen.

Werkzeuge: ESLint, Pylint, Checkstyle, RuboCop.

Formatter

Korrigiert Code-Layout: Einrückung, Klammern, Whitespace, Quote-Style.

Macht keine Logik-Aussagen.

Meist opinionated: keine Konfiguration, eine richtige Antwort.

Schreibt automatisch.

Werkzeuge: Prettier, Black, gofmt, Spotless.

Die berühmteste Faustregel: „Lint catches bugs. Format catches style." Beide laufen meist gemeinsam – Prettier formatiert, ESLint sucht Probleme. Wer beide kombiniert, hat 80 % der Code-Review-Diskussionen wegautomatisiert: niemand muss mehr über Einrückung oder ungenutzte Imports diskutieren.

2) Vorher / Nachher: was machen die Tools konkret?

Klick zwischen den Sprachen, um zu sehen, wie Linter und Formatter den Code transformieren:

Vor/Nach-Vergleich: Formatter-Effekt

Vorher

function calc( a,b ){ return a+b ; } const x=calc(1,2); if(x===3){ // alles ok }else { throw new Error("bug!"); }

Nachher

function calc(a, b) { return a + b; } const x = calc(1, 2); if (x === 3) { // alles ok } else { throw new Error("bug!"); }

Beachte: der Inhalt ist identisch, nur das Layout ist anders. Das ist die Aufgabe des Formatters – er macht keine Logik-Änderungen, nur Schönheit. Im Team-Setup einmal eingerichtet, läuft alles automatisch beim Speichern oder Committen.

3) Linter-Beispiel: was wird gefunden?

Ein konkretes Beispiel: ESLint findet in einer scheinbar harmlosen JavaScript-Funktion mehrere Probleme:

ESLint-Beispiel: kommentierte Findings

Problematischer Code

function getUser(id) { var result = db.query("SELECT * FROM users"); const name = result.name; // unused var const age = result.age; if (name == null) { return; } return result; }

ESLint-Findings

// ⚠ no-var: var verboten, // nutze let/const // ⚠ no-unused-vars: // 'age' nie genutzt // ⚠ eqeqeq: == verboten, // nutze === (strict) // ⚠ no-sql-injection: // id ignoriert! Bug! // ⚠ consistent-return: // einmal undef, einmal obj

5 Findings in 9 Zeilen Code – kein Witz. Ein Mensch hätte 1-2 davon gefunden. ESLint findet sie alle in 0,1 Sekunden. Manche kann es auto-fixen (mit eslint --fix): var → let, == → ===. Andere brauchen manuelle Entscheidung (z.B. „was sollst du zurückgeben?").

4) Die Top-Werkzeuge je Sprache

Linter und Formatter je Sprache

JavaScript / TypeScript

Linter: ESLint. Formatter: Prettier. Kombiniert via eslint-config-prettier. Quasi-Standard.

Python

Linter: Pylint oder Ruff (neuer, schnell). Formatter: Black (opinionated) oder autopep8.

Java

Linter: Checkstyle, PMD, SpotBugs. Formatter: Spotless (mit google-java-format).

Linter: golangci-lint (Sammlung). Formatter: gofmt (Standard, ohne Konfiguration).

C / C++

Linter: clang-tidy, cppcheck. Formatter: clang-format.

Rust

Linter: clippy (mit Cargo). Formatter: rustfmt. Out-of-the-Box-Integration.

CSS / SCSS

Linter: Stylelint. Formatter: Prettier kann auch CSS.

Markdown

markdownlint für einheitliche Doku-Style. Wichtig bei großen Wiki-Projekten.

5) Konfiguration: was gehört in welche Datei?

Jedes Tool hat seine eigene Config-Datei. Diese werden ins Git committed, damit alle Entwickler dieselben Regeln nutzen:

ESLint: .eslintrc.json oder eslint.config.js
Prettier: .prettierrc oder direkt in package.json
Black: Sektion in pyproject.toml
Pylint: .pylintrc oder pyproject.toml
Checkstyle: XML-Datei (z.B. checkstyle.xml)
EditorConfig (universal): .editorconfig – für IDE-übergreifende Basics (Tabs/Spaces, Charset)

EditorConfig ist erwähnenswert: ein simples Format, das jede IDE versteht. Definiert grundlegende Editor-Settings je Dateityp. Ergänzt die Sprach-spezifischen Tools.

6) Pre-Commit-Hooks: Automatisierung am Git-Hook

Die mächtigste Idee: Linter und Formatter laufen automatisch beim Committen. Wer kaputten Code committet, bekommt einen Block. So gelangt keine fehlerhafte Zeile mehr ins Repository.

Pre-Commit-Hook-Workflow

In Node-Projekten Standard: husky registriert Git-Hooks, lint-staged läuft nur über die geänderten Dateien (schnell). In Python: das Framework pre-commit macht das Gleiche. Resultat: niemand kann ungeprüften Code pushen. CI/CD (vgl. K54) prüft das Ganze nochmal serverseitig.

7) Editor-Integration

Der Idealzustand: Probleme sehen, während du tippst – nicht erst beim Committen. Alle modernen IDEs unterstützen das (vgl. L1):

VS Code: ESLint-Extension, Prettier-Extension → roter/gelber Squiggle direkt im Code.
IntelliJ: integrierte Inspections (für viele Sprachen out-of-box) plus Plugins.
„Format on Save": beim Strg+S wird formatiert. Setting in jeder modernen IDE.
Quick-Fix: Linter-Warnungen oft mit Auto-Fix-Button (Alt+Enter in IntelliJ, Ctrl+. in VS Code).

Tipp: Format on Save aktivieren. Du gewöhnst dich daran und dein Code ist immer perfekt formatiert, ohne explizit drüber nachzudenken.

8) Vor- und Nachteile

Linter sind nicht universell beliebt. Argumente dafür und dagegen:

Pro: einheitlicher Code-Stil ohne Diskussionen, frühe Bug-Erkennung, weniger Code-Review-Reibung, Onboarding-Hilfe für Neue.
Pro: Linter findet Sachen, die Menschen übersehen (Security-Issues, Type-Probleme).
Pro: Konsistenz übers ganze Team / über Jahre.
Contra: Setup-Aufwand bei Projektstart. Eingeschränkte Konfigurationsfreiheit.
Contra: False Positives – manchmal warnt der Linter ohne echten Grund.
Contra: kann nerven, wenn die Regeln zu streng sind.

Realität 2026: fast jedes Profi-Projekt nutzt Linter und Formatter. Die Diskussion ist nicht mehr „ob", sondern „welcher Regelsatz".

9) Empfehlung für Einsteiger

Wenn du in einem neuen Projekt anfängst, hier ein minimales Setup je Sprache:

JavaScript / TypeScript: npm install --save-dev eslint prettier + eslint-config-prettier. npx eslint --init für interaktives Setup.
Python: pip install ruff – moderner All-in-One, ersetzt Pylint + Black. Konfiguration in pyproject.toml.
Java: Spotless als Maven/Gradle-Plugin mit Google-Java-Format. Checkstyle für anspruchsvollere Regeln.

Plus: .editorconfig in jedem Projekt anlegen – einmal eingerichtet, kümmern sich Tabs/Spaces/Newlines von selbst.

Zusammenfassung

Linter finden Logik-Probleme (unbenutzte Variablen, Anti-Patterns, Security-Issues). Formatter korrigieren Layout (Einrückung, Quotes, Whitespace). Werkzeuge: ESLint + Prettier (JS/TS), Ruff/Pylint + Black (Python), Checkstyle + Spotless (Java). Pre-Commit-Hooks (husky, pre-commit) automatisieren das Laufen vor jedem Commit. Format on Save + IDE-Integration für Echtzeit-Feedback. .editorconfig für editor-übergreifende Basics. Nächste Lektion: Vorgehensmodelle.