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:
-
AbhÀngigkeiten installieren:
npm install --save-dev prettier eslint eslint-config-prettier husky lint-staged -
.prettierrcerstellen mit den PrÀferenzen Ihres Teams -
.editorconfigerstellen als editorĂŒbergreifende Grundlage -
ESLint konfigurieren â ausschlieĂlich mit CodequalitĂ€tsregeln (keine Formatierungsregeln)
-
Husky + lint-staged einrichten fĂŒr die Durchsetzung beim Commit
-
npm-Skripte hinzufĂŒgen:
{ "scripts": { "format": "prettier --write .", "format:check": "prettier --check .", "lint": "eslint .", "lint:fix": "eslint --fix ." } } -
Erstformatierung ausfĂŒhren fĂŒr die gesamte Codebasis:
npm run format -
Den formatierten Code committen als einzelnen Commit, damit er sich in
git blamemit--ignore-revleicht ĂŒ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.