Clean Code

... bedeutet das jeder im Team den Code leicht verstehen kann, d.h. lessbar, wartbar, erweiterbar und veränderbar ist.

(making your code readable is as important as making it executable)

Allgemein:

  • Standards verwenden
    • Coding-, architecture- and design guidelines.
  • Keep it Simple, Stupid (KISS)
    • Einfach ist immer besser, Komplexität reduzieren/vermeiden.
  • Boy Scout Rule
    • Verlasse den Code besser als du ihn vorgefunden hast.
  • Fehler-Ursachen-Analyse (Root Cause Analysis)
    • Nach der Wurzel des Übels suchen.
  • Verschiedene Sprachen in einer Datei
    • ​C#, Java, XML, HTML, XAML, Deutsch, Englisch...

Kommentare:

  • Auskommentierter Code
    • Löschen, die Informationen können im version control system gefunden werden.
  • Unangemessene Information
    • ​Wenn es wo anders besser aufgehoben wäre z.b. product backlog.
  • Nutzlos
    • Wenn der Kommentar nur das beschreibt was man eh schon durch den Code erfährt.

Namen:

  • Beschreibende bzw. eindeutige Namen
    • Sollten präzise sein und den Sinn/Inhalt wiederspiegeln.
  • Methoden-Namen
    • Sollten beschreiben was sie tun aber nicht wie es getan wird.
  • Interface-Name
    • Sollte aus deren Nutzung hergeleitet werden.
  • Klassen-Name
    • Sollten wiederspiegeln welche Interface(s) und nutzen sie erfüllen.
  • Guidelines
    • An Standards orientieren z.b. von Microsoft

Methoden:

  • Eine Sache tun
    • Unterschiedliche Funktionen auf seperate Methoden verteilen.
  • Ebene der Implemetierung beachten
    • Methoden der entsprechenden Objekte verwenden.
  • Zu viele Parameter vermeiden
    • Daten in einer seperaten "class" oder "struct" speichern.
  • Keine Flag/Switch Parameter verwenden
    • Z.b. bool flag, seperate Methoden ohne Parameter anbieten.
  • Out/Ref Parameter vermeiden
    • In mehrer Methoden aufteilen.
  • Unnötige "static" vermeiden

Klassen:

  • Single Responsibility Principle
    • Es sollte nur einen einzigen Grund geben eine Klasse zu ändern.
  • Open Closed Principle
    • Das Verhalten einer Klasse sollte erweiterbar sein ohne bestehendes Verhalten ändern zu müssen.
  • Liskov Substitution Principle
    • Abgeleitete Klassen sollten das Basisverhalten nicht verändern.
  • Dependency Inversion Principle
    • Klassen sollten von Abstraktionen(Interface) abhängen, und nicht von Details(Implementierung).
  • Interface Segregation Principle
    • Spezielle und detaillierte Interfaces für "Clients" bereitstellen.
  • Größe beachten
    • Klassen sollten klein sein, wenn nicht dann tut Sie evtl. zu viel.

Exceptions:

  • Gezielt fangen
    • Exceptions die gefangen werden sollten so genau wie möglich sein angegeben werden.
  • Sinnvoll reagieren
    • Exceptions sollte nur dann gefangen werden, wenn etwas sinnvolles damit getan werden kann.
  • Exceptions anstatt Return Codes
    • Wenn etwas nicht getan werden kann dann Exception werfen und nicht Null oder Return Codes zurück geben.
  • Schnell scheitern
    • Exceptions so früh wie möglich werfen, hilft später bei der suche des Problems.
  • Exceptions als Kontrollfluss
    • Schlechte performance, schwer zu verstehen und richtiges Fehler werden schwer zu handhaben. 
  • Exceptions schlucken
    • Nur wenn der Fehler vollständig behandelt wurde.

Design:

Abhängigkeiten: