Clean-Code-Prinzipien, die wirklich zählen

Jeder Entwickler hat "Clean Code" gelesen oder zumindest davon gehört. Das Problem ist, dass die meisten Teams es wie eine heilige Schrift behandeln statt wie einen Werkzeugkasten. Manche Prinzipien zahlen sich vom ersten Tag an aus. Andere bringen nur Ballast, der einen ausbremst, ohne einen messbaren Nutzen zu bringen. Diesen Unterschied zu erkennen, unterscheidet pragmatische Entwickler von dogmatischen.

Benennung ist die Investition mit dem höchsten ROI

Schlechte Namen sind die mit Abstand größte Quelle von Verwirrung in einer Codebasis. Eine gut benannte Funktion macht einen Kommentar überflüssig. Eine schlecht benannte Variable zwingt jeden zukünftigen Leser dazu, die Absicht dahinter mühsam zu rekonstruieren.

// ❌ What does this even mean?
const d = new Date();
const flag = process.env.FF_X;
function handle(x: unknown) {
  /* ... */
}
 
// ✅ Names carry intent — no comment needed
const subscriptionExpiresAt = new Date();
const isNewCheckoutEnabled = process.env.FF_NEW_CHECKOUT === "true";
function validatePaymentPayload(raw: unknown) {
  /* ... */
}

Die Regel ist einfach: Wenn du einen Kommentar brauchst, um zu erklären, was eine Variable oder Funktion tut, ist der Name falsch. Benenne sie um, bis der Kommentar überflüssig wird.

Kleine Funktionen, klare Grenzen

Funktionen mit mehr als 30 Zeilen erledigen fast immer mehr als eine Aufgabe. Wenn eine Funktion Validierung, Transformation und Persistierung in einem einzigen Block übernimmt, betrifft jede Änderung auch unzusammenhängende Logik.

// ❌ One function doing three jobs
async function createOrder(input: OrderInput) {
  if (!input.items.length) throw new Error("Empty cart");
  if (!input.customerId) throw new Error("Missing customer");
 
  const items = input.items.map((i) => ({
    productId: i.id,
    quantity: i.qty,
    price: i.price * (1 - (i.discount ?? 0)),
  }));
 
  const total = items.reduce((sum, i) => sum + i.price * i.quantity, 0);
 
  const order = await db.orders.create({
    data: { customerId: input.customerId, items, total },
  });
 
  await emailService.send(input.customerId, order.id);
  return order;
}
 
// ✅ Each function has one job
function validateOrderInput(input: OrderInput): void {
  if (!input.items.length) throw new Error("Empty cart");
  if (!input.customerId) throw new Error("Missing customer");
}
 
function calculateLineItems(items: CartItem[]): LineItem[] {
  return items.map((i) => ({
    productId: i.id,
    quantity: i.qty,
    price: i.price * (1 - (i.discount ?? 0)),
  }));
}
 
async function persistOrder(customerId: string, items: LineItem[]) {
  const total = items.reduce((sum, i) => sum + i.price * i.quantity, 0);
  return db.orders.create({ data: { customerId, items, total } });
}

Jede Funktion lässt sich isoliert testen. Wenn sich die Rabattlogik ändert, fasst du nur calculateLineItems an. Wenn die Persistenzschicht migriert wird, fasst du nur persistOrder an.

Toten Code konsequent entfernen

Auskommentierter Code, ungenutzte Imports und Utility-Funktionen "für alle Fälle" sind nur Rauschen. Sie erzeugen falsche Signale bei der Codesuche, verkomplizieren Diffs und untergraben das Vertrauen in die Codebasis.

// ❌ Commented-out code that "might be needed later"
// function legacyAuth(token: string) {
//   return jwt.verify(token, OLD_SECRET);
// }
 
// import { formatCurrency } from "./old-utils"; // unused
 
// ✅ Delete it. Git remembers.
// If you need it back, `git log -S "legacyAuth"` finds it instantly.

Genau dafür gibt es Versionskontrolle. Wenn jeder Entwickler seinen "könnte man noch brauchen"-Code liegen lässt, füllt sich die Codebasis mit archäologischen Schichten, die niemand mehr versteht.

Guard Clauses statt verschachtelter Bedingungen

Tiefe Verschachtelung ist einer der schnellsten Wege, Code unleserlich zu machen. Guard Clauses flachen die Logik ab und machen den Happy Path klar erkennbar.

// ❌ Deep nesting obscures the main logic
function processPayment(order: Order) {
  if (order) {
    if (order.status === "pending") {
      if (order.total > 0) {
        if (order.paymentMethod) {
          return chargeCard(order);
        } else {
          throw new Error("No payment method");
        }
      } else {
        throw new Error("Invalid total");
      }
    } else {
      throw new Error("Order not pending");
    }
  } else {
    throw new Error("No order");
  }
}
 
// ✅ Guard clauses — fail fast, then proceed
function processPayment(order: Order) {
  if (!order) throw new Error("No order");
  if (order.status !== "pending") throw new Error("Order not pending");
  if (order.total <= 0) throw new Error("Invalid total");
  if (!order.paymentMethod) throw new Error("No payment method");
 
  return chargeCard(order);
}

Die zweite Version liest sich von oben nach unten. Jede Guard Clause ist eine einzige Zeile. Die eigentliche Geschäftslogik — chargeCard(order) — hebt sich am Ende klar ab.

Konsistenz schlägt Cleverness

Eine Codebasis, in der jede Datei denselben Mustern folgt, lässt sich leichter navigieren als eine, in der jeder Entwickler seinen persönlichen Stil zur Schau stellt. Konsistenz reduziert die kognitive Last.

// ❌ Mixed patterns in the same codebase
const getUser = async (id) => await db.users.findUnique({ where: { id } });
async function fetchOrder(orderId: string): Promise<Order> {
  return db.orders.findUnique({ where: { id: orderId } });
}
 
// ✅ Pick one pattern, use it everywhere
async function getUser(id: string): Promise<User> {
  return db.users.findUnique({ where: { id } });
}
 
async function getOrder(id: string): Promise<Order> {
  return db.orders.findUnique({ where: { id } });
}

Das gilt für Namenskonventionen, Dateistruktur, die Strategie zur Fehlerbehandlung und die Reihenfolge von Imports. Automatisiere es mit Lintern und Formatierern, damit sich niemand mehr darüber Gedanken machen muss.

Was man nicht überoptimieren sollte

Manche Clean-Code-Ratschläge schaden mehr, als sie nützen, wenn man sie dogmatisch anwendet:

Das Ziel ist Klarheit, nicht die Einhaltung willkürlicher Regeln. Wenn eine 40-Zeilen-Funktion sich klar von oben nach unten liest und keine Verzweigungen hat, ist das völlig in Ordnung. Wenn eine Zwei-Zeilen-Funktion einen irreführenden Namen hat, ist es das nicht.

Die wichtigsten Punkte

1. Benennung ist dein wirkungsvollstes Refactoring — benenne um, bis Kommentare überflüssig werden
2. Kleine Funktionen mit einer einzigen Verantwortlichkeit lassen sich leichter testen, überprüfen und ersetzen
3. Lösche toten Code ohne zu zögern — die Versionskontrolle ist dein Sicherheitsnetz
4. Guard Clauses flachen die Logik ab und machen den Happy Path klar erkennbar
5. Konsistenz über die gesamte Codebasis hinweg zählt mehr als jede einzelne clevere Lösung
6. Wende Prinzipien pragmatisch an — Clean Code ist ein Werkzeug, keine Religion