Schlechter Code in der Programmierung: Was es ist, Anzeichen und wie man sauberer schreibt

Was ist schlechter Code in der Programmierung

Schlechter Code ist eine subjektive, aber allgemein anerkannte Beschreibung von Code, der nicht die minimalen Qualitätsstandards erfüllt. Robert Martin definiert in seinem Buch Clean Code (2008) schlechten Code als Code, der „daran hindert zu verstehen, was er tut“. Schlechter Code kann syntaktisch korrekt sein und sogar funktionieren, aber seine Wartung wird für das Team zum Albtraum.

Der Begriff schlechter Code ist besonders in der russischsprachigen Gemeinschaft verbreitet. Im Englischen werden formellere Begriffe verwendet: Spaghetti Code, Dirty Code, Technical Debt Code. Die emotionale Färbung von „schlechtem Code“ vermittelt jedoch genauer die Haltung der Entwickler gegenüber solchem Code — eine Mischung aus Ärger, Ekel und professioneller Beleidigung.

Laut einer McKinsey-Studie (2023) geben Unternehmen mit hoher technischer Verschuldung — und schlechter Code ist deren Hauptbestandteil — 20–40% mehr Ressourcen für die Entwicklung neuer Funktionen aus. Codequalität wirkt sich direkt auf Geschäftskennzahlen aus, und das ist keine Metapher, sondern eine bestätigte Tatsache.

Die Grenze zwischen schlechtem Code und normalem Code

Objektive Metriken gibt es nicht, aber es gibt praktische Kriterien: Wenn ein Entwickler mehr als 5 Minuten braucht, um eine 20-zeilige Funktion zu verstehen — ist es schlechter Code. Wenn die Änderung einer Zeile drei nicht zusammenhängende Module zerstört — ist es schlechter Code. Wenn Code ohne vollständiges Umschreiben nicht durch Tests abgedeckt werden kann — ist es schlechter Code.

Hauptanzeichen von schlechtem Code

Copy-Paste (Copy-Paste-Programmierung) ist eines der offensichtlichsten und am leichtesten erkennbaren Anzeichen. Wenn derselbe Codeblock mit minimalen Änderungen an mehreren Stellen wiederholt wird, ist das nicht nur schlechter Code — es ist eine Quelle zukünftiger Fehler. Die Korrektur an einer Stelle und das Übersehen an einer anderen ist eine typische Situation.

Bedeutungslose Variablennamen sind ein Klassiker. Variablen mit Namen wie `a`, `b`, `x`, `data`, `temp`, `tmp`, `result`, `list`, `obj` tragen keine Informationen über ihren Zweck. Der Code-Leser muss die gesamte Funktion analysieren, um zu verstehen, was die Variable enthält. Robert Martin nennt das „eine Lüge im Namen“ — der Name verspricht Informationen, liefert sie aber nicht.

Tiefe Verschachtelung — wenn Bedingungen, Schleifen und Fehlerbehandlung eine Struktur mit 5+ Einrückungsebenen erzeugen. Solcher Code ist ohne horizontales Scrollen oder mentales Verfolgen aller Ebenen unmöglich zu lesen. Das ist ein direkter Weg zu Fehlern: Logische Operatoren werden leicht verwechselt und schließende Klammern übersehen.

Versteckte Anzeichen

Toter Code (Dead Code) — Funktionen, Variablen, Klassen, die nirgendwo verwendet werden. Das erhöht das Codevolumen, lenkt den Entwickler ab und erzeugt einen falschen Eindruck von den Fähigkeiten des Systems. Magische Zahlen — Zahlen ohne Kontext. God-Klassen — Klassen, die alles auf einmal erledigen und gegen das Prinzip der einzigen Verantwortung (SOLID: S) verstoßen.

Warum schlechter Code entsteht

Zeitmangel ist der häufigste Grund. Wenn Termine drängen, opfern Entwickler Qualität zugunsten der Geschwindigkeit. Taktisch mag das gerechtfertigt sein, aber strategisch — ist es die Anhäufung technischer Schulden. Das Problem ist, dass „vorübergehender“ schlechter Code selten überarbeitet wird, um ihn zu beheben.

Fehlendes Code-Review ist der zweitwichtigste Grund. Wenn Code allein ohne Überprüfung durch Kollegen geschrieben wird, setzen sich schlechte Muster fest und vermehren sich. Code-Review ist nicht nur Qualitätskontrolle, sondern auch Wissenstransfer innerhalb des Teams. Projekte ohne Überprüfung verfallen unweigerlich in schlechten Code.

Niedrige Qualifikation des Entwicklers oder fehlende Mentorschaft. Juniorentwickler, die unbeaufsichtigt arbeiten, schreiben auf natürliche Weise schlechten Code — es ist Teil des Lernprozesses. Das Problem entsteht, wenn dieser Code ohne Überprüfung und Refactoring in die Produktion gelangt.

Kulturelle Faktoren

In Teams, in denen „es funktioniert, ist ja gut“ das Motto ist, gedeiht schlechter Code. Das Fehlen von Codierungsstandards, Testanforderungen und Überprüfungsprozessen schafft eine Umgebung, in der sich niemand um Codequalität kümmert. Solche Projekte werden schnell zu „Legacy“ — Code, den jeder zu berühren fürchtet.

Folgen von schlechtem Code für das Projekt

Die Hauptfolge von schlechtem Code ist die Verlangsamung der Entwicklung. Das Paradoxon schlechten Codes ist, dass er das schnelle Schreiben der ersten Version ermöglicht, aber jede nachfolgende Korrektur immer mehr Zeit in Anspruch nimmt. Der Graph der Entwicklungsgeschwindigkeit gegenüber Codequalität ist exponentiell — nach einer bestimmten Schwelle wird das Hinzufügen neuer Funktionen praktisch unmöglich.

Personalfluktuation ist eine indirekte, aber schwerwiegende Folge. Entwickler, insbesondere erfahrene, wollen nicht mit schlechtem Code arbeiten. Laut der Stack Overflow Developer Survey 2024 geben 47% der Entwickler die Qualität der Codebasis als einen der Schlüsselfaktoren bei der Wahl eines Arbeitsplatzes an. Projekte mit schlechtem Code verlieren ihre besten Mitarbeiter.

Sicherheit ist ein weiteres Opfer von schlechtem Code. Schlecht geschriebener Code enthält mehr Sicherheitslücken: nicht behandelte Ausnahmen, SQL-Injection, XSS, Speicherlecks. Qualitativ hochwertiger Code mit Unit-Tests und Code-Review fängt die meisten dieser Probleme vor der Produktion ab.

Technische Schulden als Metrik

SonarQube und ähnliche Werkzeuge können technische Schulden in Personenstunden oder -tagen schätzen. Beispielsweise ergeben 500 Warnungen zu Copy-Paste, 200 zu magischen Zahlen und 50 zu tiefer Verschachtelung eine Schätzung von 30 Tagen technischer Schulden. Diese Zahlen können und sollten dem Management gezeigt werden, um Refactoring zu rechtfertigen.

Wie man statt schlechtem Code sauberen Code schreibt

Das DRY-Prinzip (Don’t Repeat Yourself) ist das Erste, was implementiert werden sollte. Jedes Logikfragment sollte an einem einzigen Ort existieren. Statt Copy-Paste — extrahiere den sich wiederholenden Code in eine separate Funktion, Klasse oder ein Modul. Statt magischer Zahlen — benannte Konstanten. Statt langer Funktionen — mehrere kleine.

Das KISS-Prinzip (Keep It Simple, Stupid) schützt vor übermäßiger Komplexität. Wenn eine Aufgabe in 10 Zeilen gelöst werden kann — schreibe nicht 50. Wenn eine Schleife einfacher als ein Stream ist — verwende eine Schleife. Wenn eine gewöhnliche Funktion klarer als ein Dekorator ist — schreibe eine Funktion. Einfachheit ist die wichtigste Eigenschaft wartbaren Codes.

Die Boy-Scout-Regel — „hinterlasse den Code besser, als du ihn vorgefunden hast.“ Selbst kleine Verbesserungen bei jeder Bearbeitung verwandeln mit der Zeit schlechten Code in anständigen Code. Eine Variable umbenennen, eine große Funktion aufteilen, einen Test hinzufügen — jede Verbesserung zählt.

// schlechter Code — Copy-Paste, magische Zahlen, schlechte Namen
function calc(a, b, c) {
  let x = a * 0.85;
  if (b > 1000) { x = x * 0.9; }
  let y = c * 0.85;
  if (b > 1000) { y = y * 0.9; }
  return x + y;
}

// sauberer Code — klare Namen, DRY, Konstanten
const DISCOUNT_RATE = 0.85;
const BULK_THRESHOLD = 1000;
const BULK_DISCOUNT = 0.9;

function applyDiscount(amount, quantity) {
  let price = amount * DISCOUNT_RATE;
  if (quantity > BULK_THRESHOLD) {
    price = price * BULK_DISCOUNT;
  }
  return price;
}

function calculateTotal(items, quantity) {
  return items.reduce((sum, item) => {
    return sum + applyDiscount(item, quantity);
  }, 0);
}

Beispiele für Refactoring

Betrachten wir ein typisches Beispiel in Python. Die Funktion verarbeitet Bestellungen, aber auf schlechte Weise: 80 Zeilen, tiefe Verschachtelung, magische Zahlen, Duplizierung. Nach dem Refactoring wird der Code lesbar, testbar und wartbar.

# schlechter Code — eine Funktion macht alles
def process_order(order):
    if order.get("type") == "premium":
        if order["amount"] > 100:
            discount = 0.8
        else:
            discount = 0.9
    else:
        discount = 1.0
    total = order["amount"] * discount
    return total

# sauberer Code — extrahierte Funktionen und Konstanten
class OrderProcessor:
    PREMIUM_DISCOUNT_HIGH = 0.8
    PREMIUM_DISCOUNT_LOW = 0.9
    PREMIUM_THRESHOLD = 100

    def get_discount(self, order):
        if order.type == "premium" and order.amount > self.PREMIUM_THRESHOLD:
            return self.PREMIUM_DISCOUNT_HIGH
        return self.PREMIUM_DISCOUNT_LOW

    def calculate_total(self, order):
        return order.amount * self.get_discount(order)

Die Drei-Zeilen-Regel für Funktionen

Eine gute Funktion erledigt eine Sache und erledigt sie gut. Wenn eine Funktion drei verschiedene Dinge tut — teile sie auf. Wenn eine Funktion mehr als 20 Zeilen hat — kann sie wahrscheinlich aufgeteilt werden. Wenn eine Funktion mehr als zwei Einrückungsebenen hat — benötigt sie ein Refactoring.

Code-Review-Werkzeuge

Statische Code-Analysatoren sind die erste Verteidigungslinie gegen schlechten Code. ESLint (JavaScript), Pylint (Python), SonarQube (mehrsprachig), Checkstyle (Java) erkennen automatisch Copy-Paste, magische Zahlen, leere Catch-Blöcke, zu lange Funktionen und hunderte anderer Antipatterns.

Code-Stil und Formatierer sind die zweite Schutzebene. Prettier, Black, gofmt formatieren Code automatisch und beseitigen Probleme mit Leerzeichen, Einrückungen und Klammern. Ein einheitlicher Stil im Team macht Code unabhängig vom Autor lesbar. Formatierungsstreitigkeiten sollten automatisiert werden.

Code-Review ist die dritte und wichtigste Ebene. Kein Analysator kann einen Menschen ersetzen, der bemerkt, dass die Architektur der Lösung falsch ist oder der Entwickler den falschen Ansatz gewählt hat. Effektives Review kostet Zeit, aber es zahlt sich aus, indem es die Menge an schlechtem Code erheblich reduziert.

• ESLint — für JavaScript und TypeScript mit Regeln für Komplexität, max-lines, max-nested-callbacks
• Pylint — für Python mit Code-Metriken und Qualitätsbewertung (von -10 bis 10)
• SonarQube — zur Verfolgung technischer Schulden im Zeitverlauf
• CodeClimate — zur Bewertung des Wartbarkeitsindex jeder Datei
• Better Code Hub — zur Überprüfung der Einhaltung der 10 Prinzipien sauberen Codes