Das soll nicht bedeuten, dass Sie keine Kommentare mehr im Code hinterlassen dürfen. Es soll stattdessen als Anregung dienen, darüber nachzudenken, ob eine Codestelle sich nicht auch verständlicher schreiben ließe. Ein Kommentar sollte vielmehr beschreiben, was sich der Entwickler beim Schreiben gedacht hat oder was er erreichen wollte.
Die guten alten To-do-Kommentare sind erlaubt, wenn das To-do auch erledigt wird. Einen solchen Kommentar kann der Entwickler verwenden, während er noch am Code arbeitet. Streng genommen sollte ein solcher Kommentar es aber nie bis ins Repository schaffen. Sollte er doch einmal bis dorthin gelangen, muss er ein konkretes Zieldatum für die Fertigstellung enthalten.
Tools wie Javadoc erweisen sich in vielen Fällen als äußerst nützlich. Sie erstellen automatisch und quasi im Vorbeigehen die nötige Dokumentation. Das gilt aber nur, solange die entsprechenden Kommentare in Quellcode auch auf Stand sind. Darauf sollten Sie immer ein besonderes Augenmerk legen: Fast alle Entwickler verlassen sich auf eine aktuelle Dokumentation.
Variablen
Definieren Sie Variablen immer kurz bevor Sie sie im Programmcode verwenden. Dieses Vorgehen hat gleich mehrere Vorteile:
- Der Programmcode und die dazugehörige Variablendefinition passen auf eine Bildschirmseite und können so zusammen gelesen werden.
- Der Gültigkeitsbereich von Variablen ist klar definiert. Alle Variablen an den Anfang eines Programms zu schreiben, ist daher mit Abstand eine der schlechtesten Ideen, die man haben kann. Durch dieses Vorgehen würden alle Variablen quasi global.
- Viele Entwickler denken gar nicht mehr darüber nach, dass Variablen und Objekte Speicherplatz belegen und man sie daher nur definieren sollte, wenn sie tatsächlich gebraucht werden.
Am Ende braucht unsauberer Code mehr Systemressourcen. Dies hat zur Folge, dass mehr Hardware benötigt wird, die wiederum mehr Strom braucht und dadurch die Umwelt belastet. Es fällt uns Menschen offensichtlich leichter, mit realen Ressourcen sparsam umzugehen als mit virtuellen.
Methoden/Funktionen
Es gibt auch bei der Verwendung von Methoden einiges, was man besser machen kann. Wählen Sie grundsätzlich sprechende Namen für die Übergabeparameter und die Rückgabewerte. Falls die IDE diese Namen automatisch generiert, benennen Sie diese auf jeden Fall entsprechend der Funktion um.
Methoden sollten immer nur eine Aufgabe erledigen, diese aber auch vollständig. Sie sollten sich eine immer gleiche Reihenfolge der Methoden innerhalb einer Klasse angewöhnen – beispielsweise erst der Konstruktor, dann die Public-Methoden, danach die privaten Methoden.
Methoden und Funktionen enthalten idealerweise nicht mehr als sieben Anweisungen. Wird eine Methode länger, sollten Sie darüber nachdenken, sie in mehrere kleinere aufzuteilen. Es ist auch ein sinnvoller Ansatz, komplexe logische Ausdrücke aus dem if-Kommando herauszunehmen und sie in eine private Methode zu verlagern.
Methoden, die auf privaten Variablen arbeiten, sollten entweder einen Wert setzen oder einen zurückgeben (get oder set), nicht beides zusammen. Ändern Sie die Funktionsweise von Methoden nicht über Flags. In einem solchen Fall ist es besser, zwei Methoden zu schreiben und dafür keine Sonderausführungen einzubauen.
Methoden sollten nicht zu viele Parameter besitzen. Ab vier Parametern ist darüber nachzudenken, ob es nicht sinnvoll wäre, die Methode aufzuteilen. Eine weitere mögliche Lösung für dieses Problem stellt die Verwendung sogenannter Parameterobjekte dar.
Methoden sollten nach Möglichkeit die übergebenen Parameter respektive Objekte nicht modifizieren. Es ist sauberer, neue Objekte zu erzeugen und diese zurückzugeben.
Weitere Tipps
Es ist möglich, bei der Programmierung sogenannte Seiteneffekte einzusetzen. In anderen Worten: Ein Kommando erledigt mehrere Aufgaben gleichzeitig. Auf der einen Seite ist das eine praktische Herangehensweise, da das den Code sehr kurz und kompakt macht. Allerdings birgt das Vorgehen auch viele Risiken, da nicht jeder Entwickler solche Seiteneffekte im Code leicht erkennt. Schreiben Sie lieber simple und verständliche Programme als vermeintlich clevere.
Beim To-Ansatz handelt es sich um ein Top-Down-Verfahren, bei dem man eine Aufgabe in immer kleinere Teilschritte zerlegt. Die einzelnen Schritte bestehen am Ende aus einfachen, kurzen Methoden. Hier kann man auch damit beginnen, erst einmal Kommentare zu verwenden, die beschreiben, was passieren müsste. Im zweiten Schritt beginnt man damit, die konkreten Methoden zu implementieren. Beim To-Ansatz dienen die Ergebnisse einer Methode dazu, sie in die nächste weiterzureichen.
