CSharpCode
Alles über Coding Katas, Clean Code und Refactoring
Code-Duplizierung
Gleicher oder sehr ähnlicher Code kommt an mehreren Stellen vor.
Lange Methoden/Funktionen
Methoden/Funktionen sind zu lang (> 100 Zeilen). Wenn Sie zu groß sind dann tun Sie meistens viel zu viel oder enthalten Code-Duplizierungen. Methoden sollen klein und wiederverwendbar sein, dass verbessert die Wartbarkeit, die Tests und das Verständnis!
Große Klasen
Gleiches Problem wie bei den Methoden, Sie tun meist viel zu viel (Gottklasse) oder enthalten Code-Duplizierungen.
Lange Parameterlisten
Viele Parameter in einer Methode verschlechtern die Lesbarkeit. Besser direkt Objekte übergeben anstatt einzelner Eigenschaften. Es besteht natürlich auch hier wieder die Möglichkeit das die Methode auch zu viel macht und deshalb so viele Parameter benötigt!
Unterschiedliche Änderungen
Für eine Änderung muss eine Klasse an mehreren Stellen angepasst werden.
Shotgun Praxis
Das Gegenteil von gerade eben: Für eine Änderung müssen weitere Änderungen an anderen Klassen durchgeführt werden. Hier besteht natürlich die Gefahr das Sachen vergessen werden bzw. Sie schwer zu finden sind. Eine Möglichkeit wäre es die betreffenden Stellen in eine Klasse zu packen.
Neid
Eine Methode interessiert sich mehr für die Eigenschaften/Daten einer anderen Klasse als für die ihrer eigenen Klasse.
Daten Gruppieren
Eine Gruppe von Objekten kommt häufig zusammen vor bzw. als Felder in einigen Klassen und als Parameter vieler Methoden.
Einfache Datentyp Besessenheit
Auch für einfache Aufgaben sind Klassen und Objekte aussagekräftiger als elementare Typen.
Switch Anweisungen
Vererbung macht Switch-Case-Anweisungen weitgehend überflüssig und erledigt damit das Problem, dass häufig Code dupliziert werden muss.
Parallel Vererbungshierarchien
Zu jeder Unterklasse in der einen Hierarchie gibt es immer auch eine Unterklasse in einer anderen Hierarchie.
Faule Klassen
Eine Klasse leistet zu wenig, um ihre Existenz zu rechtfertigen.
Spekulative Funktionalität
Es wurden alle möglichen Spezialfälle implementiert, die aber gar nicht benötigt werden; auch solcher Code verursacht Aufwand ohne dass er etwas nützt.
Temporäre Fields
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.
Vermittler
Eine Klasse, die alle Methodenaufrufe an eine andere Klasse weiterdelegiert.
Zu Intim: Zwei oder mehrere Klassen haben zu enge Verflechtungen miteinander.
Alternative Klassen mit verschiedenen Schnittstellen
Zwei Klassen machen das gleiche, verwenden hierfür aber unterschiedliche Schnittstellen.
Inkompatible Libary Klasse
Eine Klasse einer Programmbibliothek, die Erweiterungen benötigt, um in einem für sie geeigneten Bereich verwendet werden zu können.
Daten Objekte
Klassen mit Feldern und Zugriffsmethoden ohne Funktionalität.
Falsche oder fehlende Vererbung
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.
Tiefe Verschachtelungen
Verschachtelte if/else/for/do/while-Statements machen den Code unlesbar.
Komplexe Verzweigungen
Verzweigungen, die eine Menge von Konditionen abprüfen, die mit der Funktionalität des Codeblocks nichts zu tun haben.
Über-Callback
Ein Callback, der versucht, alles zu tun.
Zu kurze Namen
Der Name einer Variable sollte ihre Funktion beschreiben. Die Verwendung von „x“, „i“ oder Abkürzungen ist zu vermeiden.
Nichtssagender Namen
Aussagekräftige Namen sind wesentlich für das Verständnis von Code.
Zu freizügig
Interne Details einer Klasse sind unnötigerweise Teil ihrer Schnittstelle nach außen.