Code Smells

Veröffentlicht auf 19. Oktober 2012

Unter Code Smells versteht man bestimmte Schwachstellen im Moduldesign oder Quellcode, welche bei einer Weiterentwicklung des Codes zu ungewollten Problemen führen können.
Es handelt sich dabei nicht um Fehler im Code und auch die Funktion wird meist nicht beeinträchtigt, sondern die betroffenen Stellen sind weniger lesbar und komplexer als nötig, was zu einer höheren Fehlerwahrscheinlichkeit bei Anpassungen führen kann.

Mitgeprägt hat den Begriff Code Smells unter anderem Kent Beck. In seinem Buch Clean Code, welches ich auch auf meiner Buchempfehlungsseite verlinkt habe, nennt er typische "Duftstellen" und bewährte Vorgehensweisen.

Kommentare
C1: Unpassende Information
C2: Veraltete Kommentare
C3: Überflüssige, offensichtliche Kommentare
C4: Schlecht formulierte Kommentare
C5: Auskommentierter Code

Umgebung
E1: Einen Build zu starten sollte nicht mehr als einen Schritt benötigen
E2: Einige Tests zu starten sollte nicht mehr als einen Schritt benötigen

Funktionen
F1: Zu viele Argumente
F2: Output Argumente. Argumente, welche einer Funktion übergeben, darin verändert und danach außerhalb weiterverwendet werden.
F3: Flag Argumente, welche zur Fallunterscheidung dienen.
F4: Tote Funktionen, welche nie verwendet werden.

Im Allgemeinen
G1: Mehrere Programmiersprachen in einer Quelldatei
G2: Offensichtliches Verhalten ist nicht umgesetzt
G3: Falsches Verhalten an den Grenzwerten
G4: Außer Kraft gesetzte Sicherheitsmechanismen
G5: Doppelter Code
G6: Code auf einem falschen Abstraktionslevel. Funktionale Implementierung sollte auf möglichst niedrigem Designlevel stattfinden.
G7: Basisklassen. Klassen, welche von eigenen abgeleiteten Klassen abhängig sind.
G8: Zu viel Information
G9: Toter Code
G10: Vertikale Trennung. Variablen und Funktionen sollten nahe ihrer Verwendung definiert werden.
G11: Widersprüchlichkeit
G12: Durcheinander
G13: Künstliches Verkuppeln. Dinge die nicht zusammengehören, sollten nicht künstlich aneinander gebunden werden.
G14: Funktionen neiden. Kein exzessiver Gebrauch von Funktionen aus anderen Klassen.
G15: Argumente zur Auswahl einer bestimmten Funktionalität innerhalb einer Methode.
G16: Verschleierte Absichten
G17: Falsch platzierte Verantwortlichkeiten (schlechtes Klassendesign)
G18: Unangebrachtes Static
G19: Nicht aussagekräftige Variablennamen
G20: Funktionsnamen, welche nicht ausssagen was sie tun.
G21: Man versteht den eigenen Algorithmus nicht
G22: Logische Abhängigkeiten sollen auch physisch vorhanden sein
G23: Bevorzuge Polymorphismus im Gegensatz zu If/Else oder Switch/Case Konstrukten
G24: Folge Standardkonventionen vor eigenen
G25: Ersetze magische Nummern mit aussagekräftigen Konstanten
G26: Sei so präzise wie möglich
G27: Struktur über Konventionen
G28: Klammere komplexere Bedingungen um Compilerabhängigkeiten zu vermeiden
G29: Vermeide negative Bedingungen
G30: Funktionen sollten nicht mehrere, sondern genau eine Sache machen
G31: Keine versteckten, zeitlich begrenzten Bindungen, Kupplungen.
G32: Keine willkürlichen Entscheidungen im Programmpfad
G33: Unbehandelte Grenzwertbedingungen
G34: Funktionen sollten nur niedrigere Funktionen aufrufen, keine höheren.
G35: Halte Konfigurationsdaten auf hohem Abstraktionslevel
G36: Vermeide Dreiecksverbindungen

Java
J1: Vermeide lange Importlisten durch die Verwendung von Wildcards
J2: Vermeide Vererbung von Konstanten
J3: Bevorzuge Konstanten vor Enumerationen

Namen
N1: Wähle erläuternde Namen
N2: Verwende Namen auf dem richtigen Abstraktionslevel
N3: Verwende Standardnomenklatur wenn möglich
N4: Verwende Eindeutige Namen
N5: Verwende lange Namen für große Aufgabenbereiche
N6: Vermeide Encodings
N7: Namen sollten Seiteneffekte beschreiben

Tests
T1: Nicht ausreichende Tests
T2: Verwende ein Testabdeckungswerkzeug!
T3: Auch triviale Tests werden durchgeführt
T4: Ein ignorierter Test bedeutet Unklarheit
T5: Prüfe Grenzwertbedingungen
T6: Teste exzessiver in der Nähe von gefundenen Fehlern
T7: Suche nach Fehlermuster
T8: Verwende Testabdeckungsmuster
T9: Tests sollten schnell durchlaufen

Ein sehr guter Foliensatz zu Code Smells mit einigen Beispielen stammt von Mario Sangiorgio.