Einleitung – Was sind Bloaters
Bloaters blasen den Source-Code auf, sie führen dazu, dass der Code groß und unüberschaubar wird. Dem Leser fällt es schwer große komplexe Methoden, Klassen und Abläufe zu überblicken und zu verstehen. Dadurch wird der Code so komplex, dass er anfällig wird für Fehler. Bugs allerdings sind wiederum schwerer zu finden, wenn sie in großen Strukturen beinhaltet sind. Menschen haben nur eine gewisse kognitive Kapazität, um komplexe Zusammenhänge im Kurzzeitgedächtnis zu halten. Diese kognitive Kapazität ist zwar von Mensch zu Mensch unterschiedlich hoch, dadurch dass sie aber nach oben hin begrenzt ist, ist es notwendig Abläufe im Programm und in Strukturen, Methoden, Klassen möglichst einfach zu halten
Long Method
Beschreibung
Lange Methoden sind der Klassiker unter den Bloaters. Diese Methoden zeichnen sich aus, dass sie so lange sind, dass sie nicht mehr überblickt werden können. Meist sind diese Methoden multifunktional. Sie machen mehrere Dinge in einer Methode und können somit meist nicht eindeutig benannt werden.
Beispiel:
Zu wenig Platz hier…
Warum ist der Source-Code schlecht?
Durch die Größe der Methode ist der Inhalt für den Leser nicht mehr greifbar. Es übersteigt die kognitive Kapazität des Lesers, der sich nicht mehr alle versteckten und verschachtelten teile der Methode merken kann und somit die Methode nicht mehr versteht. Oft erledigen diese Methode mehrere Dinge was heißt, dass das Single Responsibility Principle verletzt ist und somit führ dieses Code-Smell auch unmittelbar zu unvollständigen, oder generischen Namen oder Namen, die mit einem Bindewort verknüpft sind.
Wie wird man den Code-Smell los?
Zerteile die Methode in mehrere kleine Methoden die in einer Methode mit einem Abstraktionslevel gesammelt aufgerufen werden. Die Untermethoden werden mit ordentlichen sprechenden Namen ausgestattet passend zu den Aufgaben, die sie erfüllen. Kommentare zeigen meist Handlungsbedarf an. Sie weisen darauf hin, dass an dieser Stelle eine Untermethode ausgelagert werden sollte. Selbst kürzeste Abläufe von nur wenigen Zeilen sollten in eigene Methoden ausgelagert werden, wenn diese Erklärungsbedarf benötigen und somit zu Kommentaren zurückgegriffen werden muss.
Wie entsteht der Code-Smell?
Der Code-Smell entsteht, wenn existierende Methoden laufend erweitert werden, weil sich zum Beispiel die Anforderungen erweitern und User oder der Product-Owner wünsche einmeldet oder der Software-Engineer mehr über die Anforderungen an das Feature dazulernt. Lange Methoden sind oft auch ein Zeichen dafür, dass der Entwickler objektorientierte Programmierparadigmen nicht verstanden hat und beispielsweise auf primitive Datenstrukturen zurückgreift.
Wann ist es OK?
Lange Methode sollten prinzipiell immer vermieden werden. Es gibt jedoch sehr lange Methoden mit ausgesprochen simplem und leicht zu verstehendem Source-Code ohne Verschachtelungen und komplexen Schleifen. In diesen Fällen sind lange Methoden durchaus tolerierbar.
Large Class
Beschreibung
Klassen die dem Large Class Code-Smell entsprechen, werden oft auch als God-Classes oder Gott-Klassen bezeichnet. Das sind Klassen, die keinem eindeutigen Konzept mehr folgen und nicht mehr mit wenig aufwand interpretierbar sind. Diese Klasen erfüllen meist mehrere Zwecke und sind über die Zeit stark angewachsen.
Beispiel:
Zu wenig Platz hier…
Warum ist der Source-Code schlecht?
Die Gott-Klassen sind einerseits schwierig zu lesen und noch schwieriger zu versehen. Des Weiteren verletzten sie oft das Single Responsibility Principle und beinhalten eigentlich zwei oder mehrere Klassen in einer. Sie weisen oft viele Abhängigkeiten zu anderen Klassen auf und sind somit auch sehr schwierig zu testen. Des Weiteren werden diese Klassen meist sehr generisch benannt und haben keinen klaren spezifischen und verständlichen Namen.
Wie wird man den Code-Smell los?
Finde heraus, welche Aufgaben die Klasse erfüllt und splitte die Klasse in mehrere Klassen auf. Meist gehören gewisse Methoden oder Felder zusammen und können in einer eigenen Klasse gesammelt und repräsentiert werden.
Wie entsteht der Code-Smell?
Meist entsteht der Code-Smell indem eine Klasse laufend erweitert wird und neue Aufgaben erfüllen muss. Es werden Methoden und Felder laufend hinzugefügt und die Klasse erweitert und mächtiger gemacht. Oft ist es auch ein Zeichen, dass der Software-Engineer die stärken der Objektorientierung nicht verstanden hat und nicht von der Klasse ableitet und spezielle Anforderungen zu erfüllen. Vor allem Software-Engineers die zuvor sehr funktional oder prozedural Entwickelt haben neigen dazu die Komplexität von Klassen einfach laufend zu erhöhen und somit die Klassen wachsen zu lassen. Dieser Code-Smell geht oft auch einher mit anderen Code-Smells wie Long Method oder Primitive Obsession
Wann ist es OK?
Es kann schon sein, dass Klassen auch auf ganz normalem Weg groß und mächtig werden. Wichtig ist nach objektorientierten Grundlagen zu arbeiten und die Funktionalität gekapselt zu haben. Nicht OK sind lange Klassen, die mehrere Dinge tun und somit beispielsweise das Single Responsibility Principle.
Long Parameter List
Beschreibung
Der Lange Parameter-Liste Code-Smell tritt auf, wenn eine Methode oder ein Konstruktor zu viele Übergabeparameter hat.
Beispiel:
| Schlechter Code | Guter Code |
| void CalculateVelocity (int x1, int y1, int x2, int y2, int timeMinutes, int timeSeconds, int timeMilliSeconds, int acceleration, int startVelocity, bool round = false) {
… //calculates Velocity at a current Time between two Points with given acceleration } |
void CalculateVelocity (Point point1, Point point2, TimeStamp Time, VelocityVector vector)
{ … //calculates Velocity at a current Time between two Points with given acceleration } |
Warum ist der Source-Code schlecht?
Dieser Code-Smell ist schlecht, weil es dem Aufrufer oft nicht klar ist warum gewisse Parameter gebraucht werden. In diesem Fall die zwei Punkte. Oft wird aufgrund der langen Parameter-Liste das Single Responsibility Principle verletzt. Es werden oft auch Flag-Parameter oder Defaultparameter gesetzt die dem Aufrufer nicht klar sind. Dies führt zu Verwirrungen und kann zu Fehlern führen.
Wie wird man den Code-Smell los?
Um den Code-Smell loszuwerden müssen verschiedene Arten von Parametern unterschieden werden. Parameter die eigentlich zusammengehören, müssen als Parameter-Objekte zusammengefasst werden. Flag-Parameter müssen entfernt werden und die Methode gegebenenfalls in mehrere Submethoden oder Varianten aufgeteilt werden. Sollte die Methode das Single Responsibility Principle verletzen müssen die verschiedenen Funktionalitäten ebenfalls in mehrere Methoden zerteilt werden. Werden viele Parameter im Konstruktor verwendet eignet sich das Builder-Pattern um diesen Fall Herr zu werden
Wie entsteht der Code-Smell?
Oft entsteht dieser Code-Smell wenn ein oder mehrere Software-Engineers die Methode laufend um Funktionalität erweitern ohne grundlegend das Design der Klasse zu ändern. Es ist ebenfalls sehr häufig zu beobachten, dass Software-Engineers die aus der prozeduralen Entwicklung kommen und die objektorientierte Welt nicht gut genug kennen diesen Code-Smell gerne einbauen.
Wann ist es OK?
Bei unseren eigenen Klassen und APIs ist der Code-Smell auf jeden Fall zu vermeiden. Nur bei externen APIS die wir nicht kontrollieren und ändern können sind wir leider dazu gezwungen diese langen Parameterlisten zu akzeptieren.
Primitive Obsession
Beschreibung
Der Primitive Obsession Code-Smell besteht, wenn anstatt von Objekten höherer Abstraktion ausschließlich primitive Datentypen und generische Datenstrukturen verwendet werden.
Beispiel:
| Schlechter Code | Guter Code |
| List<T>, int, string, double, int[], string[], KeyValuePair<int,string> | Person, PhoneNumber, Phonebook, Dictionary<Id, Person>, … |
Warum ist der Source-Code schlecht?
Wenn der Primitve Obsession Code-Smell vorhanden ist, dann ist dann ist dies meist ein Zeichen von fehlendem Verständnis für Objektorientierung. Es werden somit zahlreiche Vorteile, die eine höhere Abstraktion bietet, nicht genutzt und der Source-Code bildet somit schlechter die Realität der Domäne ab. Es entsteht eine Mikroverdoppelung des zumeist stark prozeduralen Codes. Die Logik und der Status also die Daten werden außerdem nur sehr schlecht gekapselt und hängen nur sehr lose zusammen.
Wie wird man den Code-Smell los?
Felder, Listen an Parametern und Arrays können in Collection-Klassen gesammelt werden, es können auch eigene Klassen erstellt werden, in denen zunächst der Status und die Daten und danach die Logik gesammelt werden kann.
Wie entsteht der Code-Smell?
Dieser Code-Smell entsteht meist aufgrund von fehlendem Knowhow des Software-Engineers. Es kann sein, dass der Software-Engineer Defizite in objektorientierter Programmierung aufweist und zu sehr in einer prozeduralen Welt verhaftet ist. Oft fehlen dem Software-Engineer auch Skills und Fähigkeiten im Design von Software-Architekturen oder es wird zu viel an dem Wie anstatt an dem Was gearbeitet
Wann ist es OK?
Dieser Code-Smell ist nur dann in Ordnung wen es wirklich keinen Sinn macht den primitiven Datentyp zu kapseln, beispielsweise wenn nur einen State vom Backend ins Frontend durchreicht, ohne ihn zu bearbeiten oder zu validieren.
Data Clump
Beschreibung
Der Data Clump Code-Smell ist ein Spezialfall vom Primitive Obsession Code-Smell. Hierbei werden mehrere Parameter und Daten, die eigentlich logisch zusammengehören, als primitive Datenstrukturen dargestellt und durch den Code durchgereicht, ohne dabei die Daten zum Beispiel in Form einer Klasse zu kapseln.
Beispiel:
| Schlechter Code | Guter Code |
| double CalculateVelocity(int xVector, int yVector, int Acceleration, int Time){
… } |
double CalculateVelocity(VelocityVector v)
{ … } |
Warum ist der Source-Code schlecht?
Weil höhere Datentypen wie beispielsweise Klassen fehlen, wird die Domäne schlechter repräsentiert im Code Dies führt zu einer schwereren Lesbarkeit und Verständlichkeit. Es wird auch extrem viel Code verdoppelt, weil Vorteile und Stärken der objektorientierten Programmierung nicht ausgenutzt werden. Beispielsweise Methoden, Getter, Setter die Berechnungen an einer Zentralen stelle machen. Somit wird das DRY-Prinzip – Don’t Repeat Yourself also immer wieder verletzt.
Wie wird man den Code-Smell los?
Am besten wird der Code-Smell vermieden in dem Klassen benutzt werden und die stärken der Objektorientierung verwendet werden. Es können auch Parameterobjekte verwendet werden die nicht unbedingt in der Domäne repräsentiert sein müssen. Codeverdopplungen wie beispielsweise immer wieder auftauchende Berechnungen sollten in die neu entworfenen Klassen als Methoden oder in die Getter und Setter wandern.
Wie entsteht der Code-Smell?
Dieser Code-Smell entsteht ebenso wie der Primitive Obsession Smell aufgrund von fehlendem Knowhow des Software-Engineers in objektorientierten Programmierparadigmen. Meist kommen die Software-Engineers die dazu neigen Data Clumps zu produzieren aus der prozeduralen Welt und es fehlt ihnen also dementsprechend an Wissen wie objektorientiere Software-Architekturen aufgebaut werden sollen.
Wann ist es OK?
Es kann Situationen geben, in denen es keinen Sinn macht Parameterlisten zu Kapseln. In sehr vielen Fällen ist es jedoch sinnvoll. Wenn zum Beispiel ein und dasselbe Parameterset sich durch den Code durchzieht sollten Daten als Parameterobjekt gekapselt werden. In den Fällen, wo die Daten eigentlich in der Domäne als eigenes Objekt gehandhabt werden, ist es auf jeden Fall notwendig und sinnvoll eine eigene Klasse als höhere Repräsentation der Daten zu erstellen.
Deeply nested Control Flow
Beschreibung
Der Deeply nested Control Flow Code-Smell tritt auf, wenn der Software-Engineer viele if-else, switch-case, try-catch-finaly Blöcke ineinander verschachtelt und somit der Kontrollfluss des Programms nicht mehr übersichtlich ist.
Beispiel:
| Schlechter Code | Guter Code |
|
try { if(input != null) { for(int i = 0; i < input.Length; i++) { if(input[i]==searchVelocity) { count++; } if(input[i]>=max) { max= input[i]; } } } } catch (Exception ex) { … } |
try { if(input == null) { return; } count = CountVelocities(input,searchVelocity); max = FindMaxVelocity(input); } catch (Exception ex) { … } |
Warum ist der Source-Code schlecht?
Die vielen Verschachtelungen machen es dem Leser schwer die Logik zu verstehen. Normalerweise sind auch mehrere Abstraktionslevels miteinander vermischt und es fehlt meist ein höherer Abstraktionslevel, welcher die Absichten des Software-Engineers und der Domäne offenlegt und veranschaulicht. Solch ein verschachtelter Code führt zu hoher Komplexität und vielen schwer zu verstehenden Schleifen und Abläufen und ist dementsprechend schwierig zu testen und sehr fehleranfällig.
Wie wird man den Code-Smell los?
Versuche möglichst bald Konditionen zu definieren die bereits am Anfang der Methode returnen. Wenn möglich können mehrere Nested-if-else-Statements durch größere Logische ausdrücke kombiniert werden. Die Schwierigkeit bei solchen tiefen Verschachtelungen ist es eine gemeinsame „mittlere“ Abstraktionsebene zu finden. Lagere Funktionalität in eigene Submethoden auf der gleichen Abstraktionsebene aus. Sammle ggf. Logik in eignen Klassen, um die Testbarkeit zu verbessern.
Wie entsteht der Code-Smell?
Dieser Code-Smell entsteht, wenn objektorientierte Programmierparadigmen ignoriert werden oder nicht angewendet werden und der Software-Engineer nur prozedurale Ablauflogik schreibt. Es wird auf unterster Abstraktionsebene entwickelt ohne höhere Domänen-Objekte abzubilden. Methoden wachsen und wachsen um Funktionalität, wenn neue Anforderungen auftreten oder entdeckt werden.
Wann ist es OK?
Im Idealfall befindet sich in einer Methode nur ein Abstraktionslevel, in Ausnahmefällen sind auch zwei Abstraktionslevel ok, wenn dies auch nicht gerade der Leserlichkeit dient. Ab drei Abstraktionslevels sollte jedoch refactored werden.
Explicit type declaration
Beschreibung
Eine explizite Typdeklaration von lokalen Variablen oder Iterations-Variablen, obwohl var verwendet werden kann.
Beispiel:
| Schlechter Code | Guter Code |
| IList<KeyValuePair<int, string>> items = new List<KeyValuePair<int, string>>();
foreach (KeyValuePair<int, string> item in items) { // … } |
var items = new List<KeyValuePair<int, string>>();
foreach (var item in items) { // … } |
Warum ist der Source-Code schlecht?
Implizite Typdeklarationen mit dem Schlüsselwort var sparen Zeit und Tippaufwand und machen den Code leserlicher. Ein weiterer großer Vorteil ist, dass durch die Verwendung von var die Variable immer initialisiert und zugewiesen werden muss. Bei der Verwendung von Lambda-Ausdrücken mit Returnwerten die nur der Compiler kennt muss var verwendet werden, um die Variable zuweisen zu können. Wenn var verwendet wird wird außerdem das unbeabsichtigte Casten von Datentypen verhindert.
Wie wird man den Code-Smell los?
Bei lokalen Variablen und Iterations-Variablen wird das Schlüsselwort var verwendet, anstatt den Datentyp direkt und explizit zu deklarieren.
Wie entsteht der Code-Smell?
Der Code-Smell entsteht, weil sich Software-Engineers oft besser fühlen, wenn sie Variablen explizit deklarieren können. Meist mangelt es den Software-Engineers auch an Knowhow über die IDE und deren Unterstützungsmöglichkeiten oder sie haben keine professionelle IDE im Einsatz.
Wann ist es OK?
Eine explizite Typdeklaration ist dann notwendig wenn der Software-Engineer Compiler-Errors bekommen mag wenn sich der Typ im vergleich zum Rückgabetyp ändert.
Alle Code-Smells im praktischen eBook: F*ck it smells – Clean Code in C#
Weitere Blogs zum Thema Softwarequalität
Code-Smells: Object-Orientation Abusers |
Code-Smells: Couplers |
|
 |
 |
Weitere Buchempfehlungen
[Links zu Amazon]
 |
 |
 |
| [Amazon 9,99€] | [Amazon 34,99 €] | [Amazon 24,95 €] |
 |
 |
 |
| [Amazon 34,00 €] | [Amazon 25,99 €] | [Amazon 42,00 €] |
Zum Autor:
David Theil aus Linz Oberösterreich ist Digitalisierungs-Coach, Software-Engineer und als Head of Software-Development für über 30 Softwareentwickler verantwortlich. Beruflich beschäftigt er sich bereits jahrelang mit der Digitalisierung und hat bereits bei vielen Digitalisierungs-Projekten in der Wirtschaft federführend mitgewirkt. Er bewegt sich in Themen wie Digitalisierung, IoT, oder Industrie 4.0 sowohl beratend als auch praktisch mit echten Lösungen.
https://www.xing.com/profile/David_Theil
https://www.linkedin.com/in/david-theil-1a4190148/
https://www.linkedin.com/groups/8678887
DigitalisierungsCoach 