Schlechter Code beeinflusst die Produktivität negativ. Man verbringt mehr Zeit damit den Code zu verstehen und ist mehr damit beschäftig im Quelltext von einer Stelle zur anderen zu springen, um die Zusammenhänge zu erfassen, als dass man produktiven Code schreibt. Der Zeitaufwand guten Code zu schreiben macht sich immer bezahlt. Schlechter Code wird sich in jedem Projekt rächen, da er kaum wart- oder erweiterbar ist.
Aber was ist guter Code? Jeder Programmierer versteht unter gutem Code etwas anderes. Nimmt man alles zusammen, bekommt man Aussagen, die offensichtlich, der Meinung erfahrener Programmierer nach, guten Code ausmachen:
- Guter Code sollte elegant und effizient sein.
- Guter Code sollte einfach und geradeaus sein.
- Guter Code sollte von anderen Programmierern erweiter- und wartbar sein.
- Guter Code sieht aus, als wenn sich jemand um ihn "kümmert".
- Guter Code macht das, was man erwarte.
Die folgenden Tipps sind die Essenz aus dem Buch Clean Code von Robert C. Martin. Sie ersetzen natürlich nicht das Buch. Im Buch werden die Tipps ausführlich besprochen, begründet und mit Code Beispielen erläutert. Diese Liste soll lediglich dazu dienen die wichtigsten Grundsätze für sauberen und guten Code zusammengefasst als Übersicht vor sich zu haben.
Aussagekräftige Bezeichner
- Der Name eines Bezeichners sollte so gewählt werden, dass er aussagt warum die Variable, Funktion oder Klasse existiert, was sie tut und wie sie zu benutzen ist.
- Sie sollten über ihre Funktion nicht in die Irre führen.
- Man sollte keine Ziffer an Bezeichner anhängen, denn wenn sie etwas unterschiedliches bedeuten, sollten sie auch unterschiedliche Bezeichner haben.
- Überflüssige Wörter sollten nicht in Bezeichnern vorkommen.
- Es ist einfachher, wenn Bezeichner aussprechbar sind, wenn man im Team zusammenarbeitet.
- Wenn Bezeichner "suchbar" sind, fällt es leichter sie über die Suchfunktion der IDE zu finden. Bezeichner, bestehend aus einem Buchstaben, sind schwer zu finden.
- Typinformationen (Hungarische Notation) sind heutzutage Überflüssig, da man in der Regel mit typisierten Sprachen arbeitet. Änderungen des Typs würden auch immer eine Änderung des Bezeichners nach sich ziehen. Wird dies nicht konsequent gemach, ist der Bezeichner eher irre führend.
- Genau so sind Vorsilben für Attribute einer Klasse überflüssig.
- Klassen und Objekte sollten ein Nomen als Bezeichner haben, Methoden ein Verb.
- Kurze Bezeichner sind in der Regel langen Bezeichner vorzuziehen, so lange sie klar sind. Man sollte nie mehr zum Kontext hinzufügen, als absolut notwendig.
- Mit modernen IDEs ist es kein Problem den Namen eines Bezeichner mehrfach zu ändern. Man sollte sich auch nicht davor scheuen es zu tun, bis man einen zufriedenstellenden Namen gefunden hat.
Funktionen
- Funktionen sollten kurz sein.
- Sie sollten nicht so lang sein, dass sie mehrer verschachtelte Ebenen beinhalten können.
- Eine Funktion sollte eine Sache tun, die auch ihrem Bezeichner entspricht. Ist eine Funktion abschnitte unterteilt, ist dies ein Anzeichen, dass sie mehrere Dinge tun. Dies gilt auch für Boolean Parameter.
- Funktionen sollten eine Ebene der Abstraktion beinhalten.
- Funktionen sollten so wenig Parameter wie möglich haben. In Klassen können gegebenenfalls Parameter zu Attributen der Klasse gemacht werden. Zwei Parameter sind noch in Ordnung, aber es sollten in keinem Fall mehr als drei sein.
- Benötigt eine Funktion drei oder mehr Parameter, sollten diese Parameter in einer Klasse zusammengefasst werden.
- Funktionsnamen sollten aus einem Verb und einem Nomen bestehen.
- Wenn möglich, sollte man die Parameter in den Funktionsnamen unterbringen.
- Ausgabeparameter sollten vermieden werden.
- Funktionen sollten etwas tun oder etwas zurückgeben, aber nicht beides.
- Exceptions sind Fehlercodes vorzuziehen.
Kommentare
- So wenig Kommentare wie möglich, so viele Kommentare wie nötig.
- Wenn man der Meinung ist ein Kommentar schreiben zu müssen, sollte man den Code überdenken und ihn so gestallten, dass ein Kommentar üerflüssig wird.
- Kommentare sollten das ausdrücken, was der Code nicht ausdrücken kann.
- Kommentare verbessern keinen schlechten Code.
- Code sollte selbsterklärend sein.
- Gute Kommentare sagen, warum etwas gemacht wird und nicht was gemacht wird -- das sieht man am Code.
- Kommentare sollten informativ sein.
- Kommentare sollten Klarheit schaffen und nicht verwirren.
- Kommentare können vor Konsequenzen warnen oder eine Aussage bekräftigen.
- Schlechte Kommentare sind doppelte und irreführende Kommentare
- Nicht jede Funktion benötigt einen Header. Dies gilt insbesondere für kutze Funktionen mit einem gut gewählten Bezeichner.
- Historie Kommentare am Anfang des Quelltextes sind überflüssig, dazu sind Versionkontrolsysteme da.
- Nichts sagende Kommentare sind überflüssig.
- Man sollte keinen Kommentar benutzen, wenn man stattdessen eine Funktion oder Variable benutzen kann.
- Kommentare am Ende von Blöcken sind ein Zeichen, dass die Funktion zu lang ist, nicht nur eine Sache tut und zu viele verschachtelte Ebenen besitzt.
- Auskommentierter Code kann verwirren. Er sollte gelöscht werden, wir haben Versionskontrolsysteme.
Fehlerbehandlung
- Exceptions sind Fehlercodes vorzuziehen.
- Man sollten den try-except-finally-Block zu erst schreiben und dann den Code.
- Exceptions sollten informativ sein.
- Man sollte eigene Exception-Klassen benutzen.
- Der "produktive" Code sollte von der Fehlerbehandlung getrennt werden.
Oder um es mit den Worten von http://xkcd.com/ zu sagen:
