Die Familie der Dispensables- Code-Smells verkörpert all jene Code-Smells die verzichtbar und überflüssig sind und unnötig die Code-Basis aufblasen. Durch dieses Aufblasen des Source-Codes steigen die Aufwände, die in die Wartung und Weiterentwicklung der Software gesteckt werden müssen. Eine große Codebasis führt auch zu steigender Komplexität und schließlich zu einer gestiegenen Fehlerwahrscheinlichkeit.
Unnecessary Comments
Beschreibung
Kommentare sind ein heikles Thema in der Software-Engineering Community. Immer wieder flammt der eine oder andere Konflikt auf, bei dem es um den „richtigen“ Einsatz von Kommentaren geht. Dabei sollten wir Software-Engineers uns auf das wesentliche konzentrieren. Kommentare sollten nur dann geschrieben werden, wenn wie wirklich zum Verständnis des Source-Codes benötigt werden. Der Unnecessary Comments Code-Smell besteht dann, wenn Kommentare unnötig sind und nur das Wiederholen, was sowieso über den Source-Code offensichtlich verstanden werden kann.
Beispiel:
| Schlechter Code | Guter Code |
| class FlightRoute
{ // Start of route public Point Start { get; set; } // End of route public Point End { get; set; } … /// /// calculates the flight route length /// /// returns the route length public double CalcFlightLen() { var deltaX = End.X – Start.X; var deltaY = End.Y – Start.Y; //calculates the square-root of the squared sum of X and Y return Math.Sqrt(deltaX * deltaX + deltaY * deltaY) } … } |
class FlightRoute
{ public Point Start { get; set; } public Point End { get; set; } … public double CalcFlightLen() { var deltaX = End.X – Start.X; var deltaY = End.Y – Start.Y; return Math.Sqrt(deltaX * deltaX + deltaY * deltaY) } … } |
Warum ist der Source-Code schlecht?
Kommentare sind ebenso wie Logik Bestandteil des Source-Codes und müssen gelesen, verstanden und vor allem gewartet und aktuell gehalten werden. Unnötige Kommentare sollten daher vermieden werden. Wenn der Source-Code für sich verständlich ist, werden keine Kommentare benötigt. Wenn dennoch Kommentare geschrieben werden so müssen diese immer am aktuellsten Stand gehalten werden. Geschieht dies nicht, so kann es über die Zeit leicht passieren, dass Source-Code und Logik mit den Kommentaren auseinander laufen und nicht mehr konsistent sind. Unnötige Kommentare verletzen außerdem die DRY-Regel – Don’t Repeate Yourselfe.
Wie wird man den Code-Smell los?
Unnötige Kommentare bringen nichts und kosten viel. Aus diesem Grund sollten unnötige Kommentare gelöscht werden. Neue Kommentare sollten nur dann erstellt werden, wenn sie unbedingt für das Verständnis des Codes benötigt werden.
Wie entsteht der Code-Smell?
Meist werden Kommentare automatisch von der IDE generiert und der Software-Engineer befüllt diese nicht sinnvoll. Auch vom Management falsch verstandene und durchgepeitschte Coding-Standards können zu einen sinnlosen aufblasen von Source-Code durch Kommentare führen.
Wann ist es OK?
Sinnlose Kommentare sind immer zu vermeiden. Wenn Kommentare geschrieben werden sollten sie möglichst nützlich geschrieben sein.
Lazy Class
Beschreibung
Eine Lazy-Class oder auch faule Klasse ist ein Code-Smell der besteht, wenn eine Klasse so wenig macht dass dies nicht einmal ihre Existenz rechtfertigt.
Beispiel:
| Schlechter Code | Guter Code |
|
class FlightNumber { public string FlightNumberString { get; set; } public string Country { get; set; } } class FlightRoute { public FlightNumber FlightNumber {get; set;} public Point Start { get; set; } public Point End { get; set; } … public double CalcFlightLen() { var deltaX = End.X – Start.X; var deltaY = End.Y – Start.Y; return Math.Sqrt(deltaX * deltaX + deltaY * deltaY) } … } |
class FlightRoute
{ public string FlightNumber {get; set;} public string Country {get; set;} public Point Start { get; set; } public Point End { get; set; } … public double CalcFlightLen() { var deltaX = End.X – Start.X; var deltaY = End.Y – Start.Y; return Math.Sqrt(deltaX * deltaX + deltaY * deltaY) } … } |
Warum ist der Source-Code schlecht?
Der Code-Smell ist ein Problem, weil er das Design und das Klassenmodell verkompliziert und unnötige Komplexität schafft. Für den Aufrufer einer Funktion, die die Klasse verwendet oder zurückgibt oder den Verwender eines Properties ist es auf den ersten Blick nicht ersichtlich, dass die Klasse so wenig macht. Dies führt zu Verwirrungen des Software-Engineers und gegebenenfalls zu Fehlern.
Wie wird man den Code-Smell los?
Den Code-Smell kann man beseitigen indem die wenigen Methoden, Properties, und Konstanten in die aufrufenden Klassen integriert werden. Dadurch kann gegebenenfalls sogar die Hierarchie verkleinert werden, wenn die Lazy Class Teil einer Vererbungshierarchie ist.
Wie entsteht der Code-Smell?
Dieser Code-Smell entsteht meist, weil eine plangetriebene Software-Methode gewählt wurde und zu Beginn ein Klassenmodell geplant, designt und umgesetzt wurde, sich aber einige Klassen als schlichtweg unnötig herausgestellt haben und diese somit nicht weiter befüllt werden. Oft entsteht diese Vorarbeit durch Software-Architekten, die in ihren Elfenbeinturm sitzen und dem Team diktieren was es zu tun hat. Das Team wiederum traut sich nicht die Lazy Class zu beseitigen, um den Software-Architekten nicht zu verärgern. Es kann auch sein, dass diese Klassen als Überbleibsel von größeren Refactorings schlichtweg vergessen wurden. In diesem Fall ist das Refactoring aber nicht fertig und sollte dementsprechend mit der Beseitigung der Lazy Class vollendet werden.
Wann ist es OK?
Wenn Interfaces von anderen Frameworks implementiert werden müssen diese aber nicht benötigt werden kann eine Lazy Class durchaus toleriert werden.
Speculative Generality
Beschreibung
Beim Speculative Generality – Code-Smell warden Abstraktionenen geschaffen die nie genutzt werden.
Beispiel:
| Schlechter Code | Guter Code |
| · Interfaces, die erstellt werden und nie oder nur einmal implementiert werden
· Abstrakte Klassen, die nach dem Erstellen nur einmal implementiert werden · Flagparameter die nur in einer bestimmten Art und Weise gecallt werden und dementsprechende immer true oder false sind · Konfigurationen, die für alle Umgebungen gleich sind und sich nie verändern |
· Interfaces, abstrakte Klassen, Flags und Konfigurationen die auch wirklich mehrmals verwendet werden |
Warum ist der Source-Code schlecht?
Der Speculative Generality – Code-Smell verstößt gegen das YAGNI- Clean Code Principle und das KISS- Clean Code Principle. Sie generieren unnötige Komplexität und erzeugen mehr Source-Code, der gewartet wird und potentiell Fehler beinhaltet und getestet werden muss. Im Falle von nur einmaliger Implementierung verstößt der Code-Smell auch gegen das DRY – Clean Code Principle.
Wie wird man den Code-Smell los?
Parameter und Flags die nicht genutzt werden sollten entfernt werden. Bei unnötigen Hierarchie-Ebenen sollten diese, wenn möglich vereinfacht werden und Hierarchie-Ebenen herausgenommen werden.
Wie entsteht der Code-Smell?
Der Code-Smell entsteht durch ein übertriebenes Anwenden von der Software-Engineering Faustregel – „Program to an interface not to an implementation.“. Es wird oft übertrieben verallgemeinert und abstrahiert. Oftmals werden zu Beginn des Software-Engineering-Projekts zu aufwändige Pläne erstellt und diese dogmatisch umgesetzt oder zu sehr spekuliert dass ein gewisses Interface oder eine abstrakte Klasse öfter verwendet wird
Wann ist es OK?
Wenn Interfaces von anderen Frameworks verwendet werden ist es durchaus Ok dass diese nur einmal verwendet werden. Das Selbe gilt für die Bereitstellung von API- Interfaces. Außerdem kann es sein, dass Interfaces und abstrakte Klassen benötigt werden, um zyklische Abhängigkeiten zu vermeiden
Duplicated Code
Beschreibung
Codeverdopplung besteht überall dort wo ähnlicher und gleicher Code an verschiedenen Stellen dieselbe Funktionalität abbildet.
Warum ist der Source-Code schlecht?
Durch die Codeverdopplung steigt die Größe der zu wartenden Codebasis was wiederum zu gesteigerten Wartungskosten führt und potential für Fehler liefert. Mehr Source-Code bedeutet auch mehr Testfälle die benötigt sind um die notwendige Code-Qualität sicherstellen zu können. Durch die Verdopplung kann es ebenfalls passieren, dass Fehler nicht in allen Vorkommen des verdoppelten Codes ausgebessert wird und somit Fehler bestehen bleiben.
Wie wird man den Code-Smell los?
Die verdoppelte Funktionalität muss zusammengeführt werden und beispielsweise in eigenen Klassen gekapselt werden.
Wie entsteht der Code-Smell?
Der Code-Smell entsteht durch unreflektiertes Copy-Paste-Programmieren. Meist fehlt es auch an Wissen über Objektorientierung und Abstraktion.
Wann ist es OK?
Wenn möglich sollte Codeverdopplung vermieden werden und Duplikate beseitigt werden. Das Zusammenführen in eigenen Klassen führt aber zu einer gestiegenen höheren Kopplung.
Dead Code
Beschreibung
Toter Code ist all jener Source-Code der nicht aufgerufen und ausgeführt wird. Das sind all jene Methoden die Entwickelt aber niemals verwendet werden, aber auch Parameter, Properties, lokale Variablen oder Konstanten, die nie genutzt werden.
Warum ist der Source-Code schlecht?
All dieser tote Code wurde vom Software-Engineer mühsam entwickelt, was schon mal Energie und Zeit gekostet hat. Zusätzlich dazu wird der produktive Source-Code aufgeblasen. Die angewachsene Codebasis muss aber samt den toten Code gewartet werden. Doch dieses Mehr an Code führt zu gestiegener Komplexität und ist dementsprechend Fehleranfällig. Liest ein Software-Engineer den toten Code und verwendet die Funktionalität kann dies zu Fehlern führen, weil nicht bekannt ist ob der Code auch sachgemäß gewartet ist.
Wie wird man den Code-Smell los?
Toter Code muss entfernt werden. Durch die Verwendung von modernen Source-Code-Verwaltungstools wie Git kann sichergestellt werden, dass der gelöschte Code jederzeit wieder zurückgeholt werden kann.
Wie entsteht der Code-Smell?
Der Code wurde entweder erstellt aber nie verwendet, oder die Aufrufe wurden bei einem Refactoring gelöscht und nicht mehr verwendet.
Wann ist es OK?
Toter Code sollte niemals durch Bestehen lassen oder Auskommentieren erhalten werden weil er immer zu Mehraufwand und gegebenenfalls zu Fehlern führt.
Alle Code-Smells im praktischen eBook: F*ck it smells – Clean Code in C#
Weitere Blogs zum Thema Softwarequalität
Code-Smells: Confusers |
Code-Smells: Bloaters |
|
 |
 |
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 