Code Smells

Übel riechender Code (Code Smells / Bad Smells) Diese Zusammenfassung stammt aus dem Buch "Refactoring" von Martin Fowler.

  • Code-Duplizierung
    Gleicher oder sehr ähnlicher Code kommt an mehreren Stellen vor.

  • Lange Methoden/Funktionen
    Methoden/Funktionen sind zu lang (> 100 Zeilen). Wenn Sie zu groß sind dann tun Sie meistens viel zu viel oder enthalten Code-Duplizierungen. Methoden sollen klein und wiederverwendbar sein, dass verbessert die Wartbarkeit, die Tests und das Verständnis!

  • Große Klasen
    Gleiches Problem wie bei den Methoden, Sie tun meist viel zu viel (Gottklasse) oder enthalten Code-Duplizierungen.

  • Lange Parameterlisten
    Viele Parameter in einer Methode verschlechtern die Lesbarkeit. Besser direkt Objekte übergeben anstatt einzelner Eigenschaften. Es besteht natürlich auch hier wieder die Möglichkeit das die Methode auch zu viel macht und deshalb so viele Parameter benötigt!

  • Unterschiedliche Änderungen
    Für eine Änderung muss eine Klasse an mehreren Stellen angepasst werden.

  • Shotgun Praxis
    Das Gegenteil von gerade eben: Für eine Änderung müssen weitere Änderungen an anderen Klassen durchgeführt werden. Hier besteht natürlich die Gefahr das Sachen vergessen werden bzw. Sie schwer zu finden sind. Eine Möglichkeit wäre es die betreffenden Stellen in eine Klasse zu packen.

  • Neid
    Eine Methode interessiert sich mehr für die Eigenschaften/Daten einer anderen Klasse als für die ihrer eigenen Klasse.

  • Daten Gruppieren
    Eine Gruppe von Objekten kommt häufig zusammen vor bzw. als Felder in einigen Klassen und als Parameter vieler Methoden.

  • Einfache Datentyp Besessenheit
    Auch für einfache Aufgaben sind Klassen und Objekte aussagekräftiger als elementare Typen.

  • Switch Anweisungen
    Vererbung macht Switch-Case-Anweisungen weitgehend überflüssig und erledigt damit das Problem, dass häufig Code dupliziert werden muss.

  • Parallel Vererbungshierarchien
    Zu jeder Unterklasse in der einen Hierarchie gibt es immer auch eine Unterklasse in einer anderen Hierarchie.

  • Faule Klassen
    Eine Klasse leistet zu wenig, um ihre Existenz zu rechtfertigen.

  • Spekulative Funktionalität 
    Es wurden alle möglichen Spezialfälle implementiert, die aber gar nicht benötigt werden; auch solcher Code verursacht Aufwand ohne dass er etwas nützt.

  • Temporäre Fields
    Ein Objekt verwendet eine Variable nur unter bestimmten Umständen – der Code ist schwer zu verstehen und zu debuggen, weil das Feld scheinbar nicht verwendet wird.

  • Vermittler
    Eine Klasse, die alle Methodenaufrufe an eine andere Klasse weiterdelegiert.

  • Zu Intim: Zwei oder mehrere Klassen haben zu enge Verflechtungen miteinander.

  • Alternative Klassen mit verschiedenen Schnittstellen
    Zwei Klassen machen das gleiche, verwenden hierfür aber unterschiedliche Schnittstellen.

  • Inkompatible Libary Klasse
    Eine Klasse einer Programmbibliothek, die Erweiterungen benötigt, um in einem für sie geeigneten Bereich verwendet werden zu können.

  • Daten Objekte
    Klassen mit Feldern und Zugriffsmethoden ohne Funktionalität.

  • Falsche oder fehlende Vererbung
    Unterklassen brauchen die Methoden und Daten gar nicht, die sie von den Oberklassen erben (siehe auch Liskovsches Substitutionsprinzip).

  • Kommentare
    Kommentare erleichtern im Allgemeinen die Verständlichkeit. Kommentare erscheinen jedoch häufig genau dort notwendig zu sein, wo der Code schlecht ist. Kommentare können somit ein Hinweis auf schlechten Code sein.

  • Tiefe Verschachtelungen
    Verschachtelte if/else/for/do/while-Statements machen den Code unlesbar.

  • Komplexe Verzweigungen
    Verzweigungen, die eine Menge von Konditionen abprüfen, die mit der Funktionalität des Codeblocks nichts zu tun haben.

  • Über-Callback
    Ein Callback, der versucht, alles zu tun.

  • Zu kurze Namen
    Der Name einer Variable sollte ihre Funktion beschreiben. Die Verwendung von „x“, „i“ oder Abkürzungen ist zu vermeiden.

  • Nichtssagender Namen
    Aussagekräftige Namen sind wesentlich für das Verständnis von Code.

  • Zu freizügig
    Interne Details einer Klasse sind unnötigerweise Teil ihrer Schnittstelle nach außen.