JavaScript-Codeformatierung: Werkzeuge und Standards

Öffnen Sie einen beliebigen Pull Request, bei dem die Hälfte des Diffs aus Whitespace-Änderungen besteht, und Sie werden das Problem sofort spüren. Inkonsistente Formatierung verschwendet Zeit, überfrachtet Code-Reviews und erzeugt Merge-Konflikte, die nichts mit der eigentlichen Logik zu tun haben. Die Lösung ist einfach: Wählen Sie einen Formatierungsstandard, automatisieren Sie die Durchsetzung und verschwenden Sie keinen Gedanken mehr daran.

Dieser Leitfaden führt Sie durch die Werkzeuge und Standards, die JavaScript-Formatierung zu einem gelösten Problem machen.

Warum einheitliche Formatierung wichtig ist

Bei Formatierung geht es nicht um Ästhetik — es geht um die Geschwindigkeit des Teams. Wenn jeder Entwickler unterschiedliche Einrückungen, Klammerplatzierungen und Zeilenlängen verwendet, passieren drei Dinge:

Code-Reviews werden langsamer. Reviewer verschwenden mentale Energie damit, ungewohnte Formatierung zu entschlüsseln, anstatt die Logik zu bewerten. Eine Funktion, die sich vom Rest der Codebasis unterscheidet, zieht aus den falschen Gründen Aufmerksamkeit auf sich.

Merge-Konflikte häufen sich. Entwickler A formatiert eine Datei mit Tabs um, Entwickler B verwendet Leerzeichen, und plötzlich zeigt Git jede Zeile als geändert an. Der eigentliche Drei-Zeilen-Bugfix geht dabei unter.

Die kognitive Belastung steigt. Das Wechseln zwischen Dateien mit unterschiedlichen Stilen zwingt Ihr Gehirn, Strukturen ständig neu zu erfassen. Einheitliche Formatierung ermöglicht es, Code wie Fließtext zu lesen — Ihre Augen wissen instinktiv, wo sie hinschauen müssen.

Die Lösung liegt nicht darin, darüber zu streiten, welcher Stil der beste ist. Sondern darin, einen auszuwählen und ihn zu automatisieren.

Beliebte JavaScript Style Guides

Bevor Sie sich für Werkzeuge entscheiden, ist es hilfreich, die wichtigsten Style Guides zu kennen, die die Konventionen der JavaScript-Formatierung geprägt haben.

Airbnb Style Guide

Der am weitesten verbreitete JavaScript Style Guide. Er setzt Semikolons durch, bevorzugt einfache Anführungszeichen, verlangt abschließende Kommas in mehrzeiligen Konstrukten und verwendet eine Einrückung von 2 Leerzeichen. Die ESLint-Konfiguration (eslint-config-airbnb) bündelt Hunderte von Regeln, die sowohl Formatierung als auch Codequalität abdecken.

// Airbnb style
const getUserData = (userId) => {
  const user = findUser(userId);
  return {
    name: user.name,
    email: user.email,
  };
};

Standard Style

Verfolgt den entgegengesetzten Ansatz bei Semikolons — keine Semikolons, niemals. Verwendet eine Einrückung von 2 Leerzeichen und einfache Anführungszeichen. Das standard-Paket enthält einen eigenen Linter, sodass keine separate ESLint-Konfiguration benötigt wird.

// Standard style
const getUserData = (userId) => {
  const user = findUser(userId)
  return {
    name: user.name,
    email: user.email
  }
}

Google Style Guide

Ähnlich wie Airbnb, aber mit einigen Unterschieden bei den JSDoc-Anforderungen und Namenskonventionen. Verwendet eine Einrückung von 2 Leerzeichen, verlangt Semikolons und bevorzugt einfache Anführungszeichen.

Jeder dieser Style Guides hat seine Vor- und Nachteile. Entscheidend ist die Konsistenz, nicht welchen Sie wählen. Und immer mehr Teams umgehen die Debatte komplett, indem sie Prettier entscheiden lassen.

Prettier: Der meinungsstarke Formatierer

Prettier hat die JavaScript-Formatierung revolutioniert, indem es die meisten Entscheidungen überflüssig macht. Es parst Ihren Code in einen AST (Abstract Syntax Tree) und gibt ihn nach eigenen Regeln neu aus. Sie konfigurieren keine einzelnen Formatierungsoptionen — Sie legen ein paar übergeordnete Einstellungen fest, und Prettier erledigt den Rest.

Installation

npm install --save-dev prettier

Erstellen Sie eine .prettierrc-Konfigurationsdatei:

{
  "printWidth": 80,
  "tabWidth": 2,
  "useTabs": false,
  "semi": true,
  "singleQuote": true,
  "trailingComma": "all",
  "bracketSpacing": true,
  "arrowParens": "always"
}

Wichtige Konfigurationsoptionen

printWidth (Standard: 80) — Die Zeilenlänge, bei der Prettier Code umbricht. Dies ist keine harte Grenze — Prettier nutzt den Wert als Richtwert, um zu entscheiden, wann Ausdrücke auf mehrere Zeilen aufgeteilt werden. Ein Wert von 100 oder 120 ist bei Teams mit breiten Monitoren üblich.

semi (Standard: true) — Ob Semikolons am Ende von Anweisungen hinzugefügt werden. Setzen Sie den Wert auf false, wenn Sie den Standard-Style bevorzugen.

singleQuote (Standard: false) — Verwendet einfache statt doppelter Anführungszeichen. Die meisten JavaScript-Entwickler bevorzugen einfache Anführungszeichen, wodurch true die gebräuchlichere Einstellung ist.

trailingComma (Standard: "all") — Fügt abschließende Kommas überall dort ein, wo sie syntaktisch gültig sind. Das sorgt für sauberere Git-Diffs, weil das Hinzufügen eines neuen Eintrags zu einer Liste nur eine geänderte Zeile statt zwei anzeigt.

// Ohne abschließende Kommas — das Hinzufügen von "d" ändert zwei Zeilen
const items = [
-  "a",
-  "b",
-  "c"
+  "a",
+  "b",
+  "c",
+  "d"
];

// Mit abschließenden Kommas — das Hinzufügen von "d" ändert eine Zeile
const items = [
  "a",
  "b",
  "c",
+  "d",
];

arrowParens (Standard: "always") — Ob ein einzelner Parameter einer Pfeilfunktion in Klammern gesetzt wird. "always" bedeutet (x) => x, "avoid" bedeutet x => x.

Prettier ausführen

# Alle Dateien formatieren
npx prettier --write .

# Prüfen ohne Änderungen vorzunehmen
npx prettier --check .

# Bestimmte Dateitypen formatieren
npx prettier --write "src/**/*.{js,jsx,ts,tsx}"

Erstellen Sie eine .prettierignore-Datei, um generierte Dateien auszuschließen:

node_modules
dist
build
coverage
*.min.js

Wenn Sie mit minifiziertem JavaScript arbeiten, übernimmt unser Code Minifier die Minifizierung korrekt — bearbeiten Sie minifizierten Code niemals von Hand.

ESLint: Mehr als nur Formatierung

ESLint erfüllt einen anderen Zweck als Prettier. Während Prettier sich darum kümmert, wie Code aussieht, erkennt ESLint, wie sich Code verhält. ESLint-Regeln lassen sich in zwei Kategorien einteilen:

Formatierungsregeln — Einrückung, Abstände, Klammerplatzierung. Diese überschneiden sich mit Prettier und sollten im Allgemeinen deaktiviert werden, wenn beide Werkzeuge verwendet werden.

Codequalitätsregeln — unbenutzte Variablen, unerreichbarer Code, implizite Typumwandlung, fehlende Fehlerbehandlung. Hier zeigt ESLint seine wahre Stärke.

Empfohlenes Setup

npm install --save-dev eslint @eslint/js

Eine minimale eslint.config.js:

import js from '@eslint/js';

export default [
  js.configs.recommended,
  {
    rules: {
      'no-unused-vars': 'warn',
      'no-console': 'warn',
      'eqeqeq': 'error',
      'no-implicit-coercion': 'error',
    },
  },
];

Für TypeScript-Projekte fügen Sie typescript-eslint hinzu:

npm install --save-dev typescript-eslint

import js from '@eslint/js';
import tseslint from 'typescript-eslint';

export default tseslint.config(
  js.configs.recommended,
  ...tseslint.configs.recommended,
);

Prettier + ESLint Integration

Wenn beide Werkzeuge ohne Abstimmung laufen, entstehen Konflikte — ESLint-Formatierungsregeln kollidieren mit der Ausgabe von Prettier. Die Lösung ist eslint-config-prettier, das alle ESLint-Regeln deaktiviert, die mit Prettier in Konflikt stehen.

npm install --save-dev eslint-config-prettier

import js from '@eslint/js';
import prettierConfig from 'eslint-config-prettier';

export default [
  js.configs.recommended,
  prettierConfig,
  {
    rules: {
      // Hier nur Codequalitätsregeln
      'no-unused-vars': 'warn',
      'eqeqeq': 'error',
    },
  },
];

Mit diesem Setup ist Prettier für die Formatierung zuständig und ESLint für die Codequalität. Keine Konflikte, keine Verwirrung.

EditorConfig für editorübergreifende Konsistenz

Nicht jedes Teammitglied verwendet denselben Editor. EditorConfig bietet eine Grundkonfiguration, die mit VS Code, WebStorm, Vim, Sublime Text und den meisten anderen Editoren funktioniert.

Erstellen Sie eine .editorconfig-Datei im Stammverzeichnis Ihres Projekts:

root = true

[*]
indent_style = space
indent_size = 2
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true

[*.md]
trim_trailing_whitespace = false

EditorConfig kümmert sich um die Grundlagen — Einrückung, Zeilenenden, nachgestellte Leerzeichen — noch bevor Prettier überhaupt läuft. Das verhindert das häufige Problem, dass ein Windows-Entwickler \r\n-Zeilenenden in ein Unix-basiertes Projekt einschleust.

Git Hooks mit Husky und lint-staged

Automatisierte Formatierung funktioniert nur, wenn sie tatsächlich ausgeführt wird. Sich darauf zu verlassen, dass Entwickler vor jedem Commit an npx prettier --write denken, skaliert nicht. Git Hooks lösen dieses Problem.

Setup

npm install --save-dev husky lint-staged
npx husky init

Fügen Sie folgendes zur package.json hinzu:

{
  "lint-staged": {
    "*.{js,jsx,ts,tsx}": [
      "prettier --write",
      "eslint --fix"
    ],
    "*.{json,md,css}": [
      "prettier --write"
    ]
  }
}

Aktualisieren Sie den Husky Pre-Commit-Hook (.husky/pre-commit):

npx lint-staged

Jetzt formatiert jeder Commit automatisch die bereitgestellten Dateien und führt ESLint-Korrekturen durch. Entwickler müssen sich nie Gedanken über Formatierung machen — sie passiert einfach von selbst.

Das ist der Goldstandard für Teamprojekte: Prettier formatiert, ESLint findet Fehler, Husky erzwingt beides bei jedem Commit.

Die Semikolon-Debatte

Keine Diskussion über JavaScript-Formatierung ist vollständig ohne die Semikolon-Frage. Hier die pragmatische Antwort: Es spielt keine Rolle, solange Ihr Team konsistent vorgeht.

Pro Semikolons: Explizite Anweisungsabschlüsse vermeiden Sonderfälle bei ASI (Automatic Semicolon Insertion). Die Style Guides von Airbnb und Google verlangen sie.

Ohne Semikolons: JavaScripts ASI übernimmt die Terminierung automatisch. Der Code ist sauberer und visuell ruhiger. Der Standard Style Guide verzichtet darauf.

Die ASI-Fallstricke, vor denen häufig gewarnt wird — etwa Zeilen, die mit ( oder [ beginnen — werden durch ESLints Regel no-unexpected-multiline abgefangen. In der Praxis ist der Verzicht auf Semikolons mit ordentlichem Linting absolut sicher.

Entscheiden Sie sich für eine Variante, konfigurieren Sie Prettiers semi-Option entsprechend, und haken Sie das Thema ab. Prettier fügt Semikolons konsistent hinzu oder entfernt sie — ganz gleich, wie Sie sich entscheiden.

Tabs vs. Leerzeichen in JavaScript

Das JavaScript-Ökosystem verwendet ganz überwiegend Leerzeichen — genauer gesagt eine Einrückung von 2 Leerzeichen. Das ist nicht universell (Go verwendet Tabs, Python verwendet 4 Leerzeichen), aber in JavaScript ist es die klar vorherrschende Konvention.

Warum 2 Leerzeichen? JavaScripts verschachtelte Callback-Muster und verkettete Methoden erzeugen schnell tiefe Einrückungen. Zwei Leerzeichen halten tief verschachtelten Code lesbar, ohne ihn über den rechten Bildschirmrand hinaus zu schieben.

Warum keine Tabs? Tabs erlauben es jedem Entwickler, die eigene Darstellungsbreite festzulegen, was zunächst gut klingt, aber bedeutet, dass Code-Ausrichtung in verschiedenen Editoren nicht mehr stimmt. Mit Leerzeichen sieht jeder dasselbe.

Konfigurieren Sie das einmal in Prettier (tabWidth: 2, useTabs: false) und EditorConfig (indent_style = space, indent_size = 2), und die Sache ist erledigt.

Häufige Formatierungsfallen

Inkonsistente Pfeilfunktionen

// Inkonsistent — vermeiden
const double = x => x * 2;
const add = (a, b) => a + b;
const greet = (name) => {
  return `Hello, ${name}`;
};

// Konsistent — Prettier mit arrowParens: "always"
const double = (x) => x * 2;
const add = (a, b) => a + b;
const greet = (name) => {
  return `Hello, ${name}`;
};

Objekt-Destrukturierung

// Zusammengedrängt — schwer lesbar
const {name,email,role} = user;

// Formatiert — Prettier erledigt das automatisch
const { name, email, role } = user;

// Mehrzeilig bei vielen Eigenschaften
const {
  name,
  email,
  role,
  department,
  startDate,
} = user;

Organisation von Import-Anweisungen

Prettier sortiert keine Imports — das ist eine Frage der Codequalität, nicht der Formatierung. Verwenden Sie eslint-plugin-import oder das Plugin simple-import-sort:

// Organisierte Imports
import React from 'react';
import { useState, useEffect } from 'react';

import { Button } from '@/components/Button';
import { Modal } from '@/components/Modal';

import { formatDate } from '../utils/dates';
import { validateEmail } from '../utils/validation';

Lange ternäre Ausdrücke

// Unlesbar in einer Zeile
const label = isAdmin ? 'Admin Dashboard' : hasEditPermission ? 'Editor View' : 'Read Only';

// Prettier formatiert in lesbares Mehrzeilen-Format um
const label = isAdmin
  ? 'Admin Dashboard'
  : hasEditPermission
    ? 'Editor View'
    : 'Read Only';

Ein neues Projekt einrichten

Hier ist eine vollständige Checkliste für die Einrichtung eines neuen JavaScript- oder TypeScript-Projekts:

1. Abhängigkeiten installieren:

   npm install --save-dev prettier eslint eslint-config-prettier husky lint-staged
   

2. .prettierrc erstellen mit den Präferenzen Ihres Teams

3. .editorconfig erstellen als editorübergreifende Grundlage

4. ESLint konfigurieren — ausschließlich mit Codequalitätsregeln (keine Formatierungsregeln)

5. Husky + lint-staged einrichten für die Durchsetzung beim Commit

6. npm-Skripte hinzufügen:

   {
     "scripts": {
       "format": "prettier --write .",
       "format:check": "prettier --check .",
       "lint": "eslint .",
       "lint:fix": "eslint --fix ."
     }
   }
   

7. Erstformatierung ausführen für die gesamte Codebasis: npm run format

8. Den formatierten Code committen als einzelnen Commit, damit er sich in git blame mit --ignore-rev leicht überspringen lässt

Formatierung in der Praxis

Sobald Ihre Formatierungs-Pipeline eingerichtet ist, verändert sich der Arbeitsalltag grundlegend:

• Schreiben Sie Code, wie Sie möchten. Prettier formatiert beim Speichern oder Committen um.
• Pull Requests zeigen nur Logikänderungen. Kein Whitespace-Rauschen mehr.
• Neue Teammitglieder sind sofort produktiv. Die Werkzeuge setzen Standards durch, ohne dass ein Styleguide-Dokument nötig wäre.
• Diskussionen über Stil verschwinden. Prettier ist die Autorität, nicht ein einzelner Entwickler.

Wenn Sie die Struktur von JSON-Daten überprüfen möchten, mit denen Sie arbeiten, macht unser JSON Formatter die Inspektion einfach — fügen Sie beliebiges JSON ein und erhalten Sie sofort eine gut lesbare Formatierung direkt im Browser.

Weiterführende Ressourcen

Mehr zum Thema Codeformatierung und Entwicklerwerkzeuge:

• Code Minification Guide — Erfahren Sie, wann und wie Sie JavaScript für die Produktion minifizieren
• Naming Conventions in Programming — Einheitliche Benennung ist die zweite Hälfte lesbaren Codes
• SQL Formatting Best Practices — Wenden Sie dieselbe Formatierungsdisziplin auf Ihre Datenbankabfragen an

Einheitliche Formatierung gehört zu den seltenen technischen Investitionen, die sich sofort auszahlen und das auch weiterhin tun. Richten Sie sie einmal ein, automatisieren Sie sie, und verwenden Sie Ihre Energie für den Code, der wirklich zählt.