JavaScript Formatieren

Der formatierte Code

Wenn du den Formatierer auf das minifizierte JavaScript oben anwendest, erhältst du:

const calculateTotal = (items, discount) => {
  let total = 0;
  for (const item of items) {
    total += item.price * item.quantity;
  }
  if (discount > 0) {
    total = total * (1 - discount / 100);
  }
  return Math.round(total * 100) / 100;
};

const formatCurrency = (amount) =>
  new Intl.NumberFormat("en-US", {
    style: "currency",
    currency: "USD",
  }).format(amount);

async function fetchProducts(category) {
  const response = await fetch(`/api/products?category=${category}`);
  if (!response.ok) {
    throw new Error(`HTTP ${response.status}`);
  }
  const data = await response.json();
  return data.products
    .filter((p) => p.inStock)
    .sort((a, b) => a.price - b.price);
}

export { calculateTotal, formatCurrency, fetchProducts };

Jede Anweisung erhält eine eigene Zeile. Arrow-Function-Körper werden umbrochen, wenn sie die Druckbreite überschreiten. Nachgestellte Kommas werden in mehrzeiligen Konstrukten ergänzt, damit Diffs sauberer aussehen.

Warum JavaScript-Formatierung wichtig ist

Unformatiertes JavaScript ist eine Wartungslast. Eine minifizierte Einzeiler-Funktion funktioniert beim Schreiben, wird aber in dem Moment unlesbar, in dem jemand anderes sie ändern muss. Formatierung macht mehrere Dinge schneller:

Code-Review. Ein Reviewer kann Funktionslogik, Argument-Destructuring und Kontrollfluss unabhängig voneinander prüfen, wenn jede Anweisung in einer eigenen Zeile steht. Eine einzeilige Funktion erfordert, den gesamten String gedanklich zu parsen, um irgendeinen Teil davon zu verifizieren.

Debugging. Wenn eine Funktion falsche Ergebnisse liefert, isolierst du das Problem normalerweise, indem du console.log-Anweisungen hinzufügst oder Zeilen auskommentierst. Mit korrekt formatiertem Code ist dieser Vorgang unkompliziert.

Pull-Request-Diffs. Eine Änderung an einer Bedingung sollte im Diff als einzelne geänderte Zeile erscheinen. In einer minifizierten Datei berührt jede Änderung die gesamte Zeile, wodurch der Diff für Reviews nutzlos wird.

Stilentscheidungen von Prettier

Der Formatierer verwendet die festen Standardvorgaben von Prettier. Diese sind in diesem Werkzeug nicht konfigurierbar, decken aber die gängigsten Konventionen ab:

Semikolons: Werden immer gesetzt. Das verhindert ASI-Fehler (automatic semicolon insertion), die schwer zu debuggen sind.

Anführungszeichen: Doppelte Anführungszeichen für Strings. Das ist die Prettier-Standardeinstellung und vermeidet Escaping, wenn Strings Apostrophe enthalten.

Nachgestellte Kommas: Werden in mehrzeiligen Arrays, Objekten und Funktionsparametern gesetzt. Das erzeugt sauberere Git-Diffs, weil das letzte Element geändert werden kann, ohne ein Komma in der vorherigen Zeile zu ergänzen.

Einrückung: 2 Leerzeichen. Das ist die gängigste Konvention in JavaScript-Projekten und entspricht der Standardeinstellung der meisten Linter und Editoren.

Druckbreite: 80 Zeichen. Zeilen, die darüber hinausgehen, werden an logischen Stellen umbrochen (nach Pfeilen, vor Operatoren, an Argumentgrenzen).

Wann du Prettier nicht verwenden solltest

Prettier ist ein Code-Formatierer, kein Linter. Es findet keine Fehler, erzwingt keine Best Practices und meldet keine ungenutzten Variablen. Verwende dafür ESLint. Prettier kümmert sich auch nicht um die Code-Organisation: Es verschiebt keine Funktionen zwischen Dateien, sortiert keine Imports um (außer mit einem Plugin konfiguriert) und strukturiert dein Modulsystem nicht um. Manche Codestile sind für bestimmte Anwendungsfälle wirklich besser als die Prettier-Standards: Tabs zur Einrückung, einfache Anführungszeichen, keine Semikolons. Wenn dein Projekt einen etablierten Stil hat, der von den Prettier-Standards abweicht, konfiguriere Prettier entsprechend oder verwende einen anderen Formatierer.