Smell (Programmierung)

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche

Unter Code-Smell, kurz Smell (deutsch ‚[schlechter] Geruch‘) oder deutsch übelriechender Code versteht man in der Programmierung ein Konstrukt, das eine Überarbeitung des Programm-Quelltextes nahelegt. Dem Vernehmen nach stammt die Metapher Smell von Kent Beck und erlangte weite Verbreitung durch das Buch Refactoring von Martin Fowler. Unter dem Begriff sollten handfestere Kriterien für Refactoring beschrieben werden, als das durch den vagen Hinweis auf Programmästhetik geschehen würde.

Bei Code-Smell geht es zunächst nicht um Programmfehler. Vielmehr handelt es sich um funktionierenden Programmcode, der schlecht strukturiert ist. Das größte Problem liegt darin, dass der Code für den Programmierer schwer verständlich ist, so dass sich bei Korrekturen und Erweiterungen häufig wieder neue Fehler einschleichen. Code-Smell kann auch auf ein tieferes Problem hinweisen, das in der schlechten Struktur verborgen liegt und erst durch eine Überarbeitung erkannt wird.

Verbreitete Smells[Bearbeiten]

Die folgenden von Martin Fowler und Kent Beck beschriebenen Smells[1] beziehen sich auf die objektorientierte Programmierung, haben aber naheliegende Entsprechungen unter anderen Programmier-Paradigmen.

Code-Duplizierung
Der gleiche Code kommt an verschiedenen Stellen vor.
Lange Methode
Eine Methode (Funktion, Prozedur) ist zu lang.
Große Klasse
Eine Klasse ist zu umfangreich, umfasst zu viele Instanzvariablen und duplizierten Code. Siehe auch Gottobjekt
Lange Parameterliste
Anstatt ein Objekt an eine Methode zu übergeben, werden Objekt-Attribute extrahiert und der Methode als lange Parameterliste übergeben.
Divergierende Änderungen
Für eine Änderung muss eine Klasse an mehreren Stellen angepasst werden.
Schrotkugeln herausoperieren (engl. Shotgun Surgery)
Das Gegenteil von divergierenden Änderungen: Für eine Änderung müssen weitere Änderungen an vielen Klassen durchgeführt werden.
Neid (engl. Feature Envy)
Eine Methode interessiert sich mehr für die Eigenschaften – insbesondere die Daten – einer anderen Klasse als für jene ihrer eigenen Klasse.
Datenklumpen
Eine Gruppe von Objekten kommt häufig zusammen vor: als Felder in einigen Klassen und als Parameter vieler Methoden.
Neigung zu elementaren Typen (engl. Primitive Obsession)
Auch für einfache Aufgaben sind Klassen und Objekte aussagekräftiger als elementare Typen.
Case-Anweisungen in objektorientiertem Code
Polymorphismus macht Switch-Case-Anweisungen weitgehend überflüssig und erledigt das damit zusammenhängende Problem des duplizierten Codes.
Parallele Vererbungshierarchien
Zu jeder Unterklasse in der einen Hierarchie gibt es immer auch eine Unterklasse in einer anderen Hierarchie.
Faule Klasse
Eine Klasse leistet zu wenig, um ihre Existenz zu rechtfertigen.
Spekulative Allgemeinheit
Es wurden alle möglichen Spezialfälle vorgesehen, die gar nicht benötigt werden; solch allgemeiner Code braucht Aufwand in der Pflege, ohne dass er etwas nützt.
Temporäre Felder
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.
Nachrichtenketten
Das Gesetz von Demeter wird verletzt.
Middle Man (Vermittler)
Eine Klasse, die alle Methodenaufrufe an eine andere Klasse weiterdelegiert.
Unangebrachte Intimität
Zwei Klassen haben zu enge Verflechtungen miteinander.
Alternative Klassen mit verschiedenen Schnittstellen
Zwei Klassen machen das gleiche, verwenden hierfür aber unterschiedliche Schnittstellen.
Inkomplette Bibliotheksklasse
Eine Klasse einer Programmbibliothek, die Erweiterungen benötigt, um in einem für sie geeigneten Bereich verwendet werden zu können.
Datenklasse
Klassen mit Feldern und Zugriffsmethoden ohne Funktionalität. Oft zu finden in einem sogenannten anämischen Fachmodell.
Ausgeschlagenes Erbe (engl. Refused Bequest)
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.

Weitere Smells und Programmierungs-Anti-Pattern[Bearbeiten]

Neben den von Fowler erwähnte Smells gibt es noch eine Reihe von Code-Smells die oft auch unter Programmierungs-Anti-Pattern erwähnt werden:

Nichtssagender Name (engl. Uncommunicative Name)
Aussagekräftige Namen sind wesentlich für das Verständnis von Programmcode.
Redundanter Code
Ein Stück Code, das nicht (mehr) verwendet wird.
Indecent Exposure (engl.)
Interne Details einer Klasse sind unnötigerweise Teil ihrer Schnittstelle nach außen.
Contrived complexity (engl.)
Erzwungene Verwendung von Entwurfsmustern, wo einfacheres Design ausreichen würde.
Zu lange Namen
Insbesondere die Verwendung von Architektur- oder Designbestandteilen in den Namen von Klassen oder Methoden.
Zu kurze Namen
Der Name einer Variable sollte ihre Funktion beschreiben. Die Verwendung von „x“, „i“ oder Abkürzungen ist zu vermeiden.
Über-Callback
Ein Callback, der versucht, alles zu tun.
Komplexe Verzweigungen
Verzweigungen, die eine Menge von Konditionen abprüfen, die mit der Funktionalität des Codeblocks nichts zu tun haben.
Tiefe Verschachtelungen
Verschachtelte if/else/for/do/while-Statements machen den Code unlesbar.

Architektur-Smells[Bearbeiten]

Neben den von Beck und Fowler adressierten Smells im Quelltext von Anwendungen treten Smells auch in der Architektur von Softwaresystemen auf. Diese wurden von Stefan Roock und Martin Lippert beschrieben.

Zu den Architektur-Smells zählen unter Anderem:

  • Zyklische Benutzungsbeziehungen zwischen Paketen, Schichten und Subsystemen
  • Größe und Aufteilung der Pakete oder Subsysteme

Siehe auch[Bearbeiten]

Literatur[Bearbeiten]

  •  Martin Fowler: Refactoring. Wie Sie das Design vorhandener Software verbessern. Addison-Wesley, München 2000 (Originaltitel: Refactoring. Improving The Design Of Existing Code, übersetzt von Bernd Kahlbrandt), ISBN 3-8273-1630-8, S. 67–82.

Weblinks[Bearbeiten]

  • Refactoring Eine Überblicksarbeit, die im Abschnitt 2.3 unter dem Titel "Bad Smells" einige wichtige Smells erklärt.

Einzelnachweise[Bearbeiten]

  1.  Martin Fowler: Refactoring. Wie Sie das Design vorhandener Software verbessern. Addison-Wesley, München 2000 (Originaltitel: Refactoring. Improving The Design Of Existing Code, übersetzt von Bernd Kahlbrandt), ISBN 3-8273-1630-8, S. 67–82.