Smell (Programmierung)

Unter Code-Smell, kurz Smell (engl. ‚[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

Die klassischen, von Martin Fowler und Kent Beck beschriebenen Smells beziehen sich auf die objektorientierte Programmierung, haben aber ihre naheliegenden 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 vermutlich auch duplizierten Code

Lange Parameterliste

Es werden mehr Parameter übergeben als unbedingt nötig

Nichtssagender Name (engl. Uncommunicative Name)

Aussagekräftige Namen sind wesentlich für das Verständnis von Programmcode

Divergierende Änderungen

Dieselbe Klasse muss aus verschiedenen Gründen in unterschiedlicher Weise verändert werden

Schrotkugeln herausoperieren (engl. Shotgun Surgery)

Für eine Änderung müssen viele kleine Änderungen an vielen Klassen gemacht werden

Faule Klasse

Eine Klasse leistet zu wenig, um ihre Existenz zu rechtfertigen

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

Toter Code

Ein Stück Code, das überhaupt nicht (mehr) verwendet wird

Spekulative Allgemeinheit

Es wurden alle möglichen Spezialfälle vorgesehen, die überhaupt nie benötigt werden; solcher allgemeiner Code braucht nur 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

Indecent Exposure (engl.)

Interne Details einer Klasse sind unnötigerweise Teil ihrer Schnittstelle nach außen

Nachrichtenketten

Das Gesetz von Demeter wird verletzt

Middle Man (Vermittler)

Eine Klasse, die alle Methodenaufrufe an andere Klassen weiterdelegiert

Unangebrachte Intimität

Zwei Klassen haben zu enge Verflechtungen miteinander

Ausgeschlagenes Erbe (engl. Refused Bequest)

Unterklassen brauchen die Methoden und Daten gar nicht, die sie von den Oberklassen erben (siehe auch Liskovsches Substitutionsprinzip)

Alternative Klassen mit verschiedenen Schnittstellen

Zwei Klassen machen das gleiche, verwenden hierfür aber unterschiedliche Schnittstellen

Kommentare

Kommentare sind in der Sprache der Smells zwar ein guter Geruch, werden aber oft wie Deodorant eingesetzt, das einen üblen Geruch überdeckt: wo ein Kommentar notwendig scheint, ist häufig der Code schlecht

Architektur-Smells

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

• Anti-Pattern

Literatur

• 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

• Code Smell (empros Gmbh) Überblick über Smells mit (teilweise unüblichen) eingedeutschten Namen.
• Refactoring Eine Überblicksarbeit, die im Abschnitt 2.3 unter dem Titel "Bad Smells" einige wichtige Smells erklärt.