Programme werden von Computern ausgeführt, aber von Menschen gelesen. Dem Computer ist es egal, wie der Programmcode formatiert ist, ob eine Funktion xp5q3 oder isEmpty heißt, und ob Kommentare vorhanden sind. Ein Mensch aber, der das Programm vielleicht weiterentwickeln möchte, ist darauf angewiesen, dass es lesbar ist. Dies betrifft auch den Autor des Programms selbst, der nach einem halben Jahr meist auch nicht mehr weiß, was die Funktion neu_berech1 genau tun sollte.
Die Anforderungen an die Qualität von Software umfassen nicht nur
sondern auch
Zur Struktur gehört die Architektur des Systems, also die zweckmäßige Aufteilung des Programms in Pakete, Klassen und Funktionen. Zur Struktur im weiteren Sinn gehört aber auch die Übersichtlichkeit des Programms, beginnend bei einer sauberen Formatierung über geeignete Benennungen von Klassen, Funktionen und Variablen bis hin zu einer sinnvollen Kommentierung wichtiger Programmstücke.
Die Kriterien für eine gute Softwarestruktur sind also
Ein Programm ist nur dann übersichtlich, wenn man es auch tatsächlich übersehen bzw. überblicken kann. Dies ist der Fall, wenn jede Funktion auf eine Bildschirmseite passt (bei großen Bildschirmen: auf eine halbe Bildschirmseite).
Wenn Sie merken, dass eine Funktion länger wird, ist es Zeit, sich über eine weitergehende Strukturierung der Funktion Gedanken zu machen. Lagern Sie dann zusammengehörige Teile der Funktion in jeweils eigene Funktionen aus.
Führen Sie Funktionen nicht nur für den Fall ein, dass ein Programmstück mehrfach gebraucht wird, sondern auch zum reinen Zweck der Strukturierung des Programms.
Selbst einfachste Programme sind schwer zu verstehen, wenn der Programmcode nicht sauber formatiert ist.
Software-Entwurfs-Umgebungen wie Eclipse ermöglichen eine automatische Formatierung des Programmcodes. Stellen Sie die Formatierung so ein, dass zusammengehörige geschweifte Klammern immer übereinander stehen und dass der dazwischen stehende Programmcode deutlich eingerückt ist:
Häufig anzutreffen ist eine Formatierung in der Weise, dass die öffnende geschweifte Klammer nicht in eine eigene Zeile gesetzt wird:
Hierdurch wird zwar Platz gespart, aber Übersichtlichkeit entsteht gerade dadurch, dass großzügig mit Platz umgegangen wird. Daher ist von dieser Art der Formatierung abzuraten.
Genauso schwierig, aber auch genauso wichtig wie das Programmieren selbst ist es, treffende Benennungen für Klassen, Funktionen und Variablen zu finden.
Investieren Sie hierfür genügend Zeit. Es ist eine Investition, die sich auszahlt: Sie benötigen später dafür umso weniger Zeit, um Ihr eigenes Programm zu verstehen.
Wenn Sie merken, dass Sie eine etwa Funktion oder Variable ungeschickt benannt haben, können Sie durch Refactoring diesen Mangel schnell beheben.
Es ist sinnvoll, Englisch als Sprache für die Benennung von Klassen, Funktionen und Variablen zu verwenden und sich dabei an bestimmte Konventionen der Schreibweise zu halten.
Position, Client, BoardIterator
(großer Anfangsbuchstabe, intern ggf. weitere Großbuchstaben (camel case)).
Je nach Rückgabetyp:
(kleiner Anfangsbuchstabe, intern ggf. Großbuchstaben (camel case))
i, p, pos, lastmove, startfields (nur Kleinbuchstaben)
Für lokale Variablen und Parameter genügen kurze Namen wie a, i, und n. Denn diese Variablen haben ja nur einen kurzen Gültigkeitsbereich, und dort können wir uns den Verwendungszweck etwa eines Arrays merken, auch wenn es einfach a heißt.
Also nicht so:
sondern so:
Globale Variablen und Objektattribute sollten dagegen längere Namen haben, da sie einen größeren Gültigkeitsbereich haben, also z.B. lastmove, startfields usw. Wenn wir ein Objektattribut statt lastmove einfach m nennen, besteht zudem die Gefahr von Verwechslungen mit lokalen Variablen namens m.
Abzuraten ist davon, den Typ einer Variablen in ihrem Namen mitzucodieren, also die Benennung iCnt für eine Variable vom Typ int oder strZeile für eine Variable vom Typ String oder objDatei für eine Variable vom Typ Object.
Die Lesbarkeit leidet erheblich, und der Typ der Variablen lässt sich leicht anhand ihrer Deklaration feststellen. Moderne Entwicklungsumgebungen zeigen im Übrigen auch den Typ einer Variablen an, wenn man mit dem Mauszeiger darüberfährt (Bild 1).
Bild 1: Anzeige des Typs einer Variablen mit dem Mauszeiger
Sinnvolle Kommentare an den entscheidenden Stellen des Programms ermöglichen ein leichtes Verständnis. Kommentierung hat aber auch Rückwirkungen auf das Programmieren selbst: Wir merken, dass wir eine Funktion wohl schlecht implementiert haben, wenn wir nur einen sehr umständlichen Kommentar über ihre Arbeitsweise zustande bringen.
Kommentare sind auch in deutscher Sprache zulässig, jedenfalls solange Sie nicht in einem internationalen Entwicklerteam arbeiten.
Beschreiben Sie über jeder Funktion den Zweck der Funktion; nennen Sie dabei die Argumente und den Rückgabewert:
Bei längeren Funktionen erläutern Sie kurz die Arbeitsweise der Funktion:
Mit Zeilenkommentaren können Sie den Zweck bestimmter Anweisungen erläutern, wenn diese nicht selbsterklärend sind:
Vermeiden Sie jedoch überflüssige Kommentare:
Schreiben Sie insgesamt nicht so viel Kommentar, dass der Programmcode darin untergeht. Das Programm sollte immer noch als zusammenhängendes Ganzes erkennbar bleiben.
[Mar 09] R.C. Martin: Clean Code. Prentice Hall (2009)
[Fow 99] M. Fowler: Refactoring. Addison-Wesley (1999)