Angehenden Programmierern und denen, die sich noch nicht andersweitig festgelegt haben, möchte ich folgende Regeln ans Herz legen.

1. Führe eine To-Do-Liste
   Eine To-Do-Liste hat zwei Aufgaben. Sie ist erstens dazu da, Ideen festzuhalten, die im Verlauf des Entwicklungsprozesses oder auch schon davor auftauchen, aber noch nicht umgesetzt worden sind, und zweitens um stets zu wissen, woran man gerade arbeitet und entsprechend was als nächstes zu tun ist.
   Letzteres notiere ich bei manchen Projekten auch auch gerne direkt und nicht auskommentiert im Quellcode. So tritt bei der nächsten Benutzung ein Fehler auf, der mich unweigerlich daran erinnert, was zu tun ist.
   Es empfiehlt sich, für jedes Projekt eine eigene Liste zu haben.
   Als Liste selbst eignet sich eine simple Text-Datei oder bei der Verwendung einer Entwicklungsumgebung eine zum Projekt gehörende Datei (z.B. in Kommentar im Quellcode).
   Ist die Liste gerade nicht zur Hand, so notiere ich die Gedanken gerne in einer Mail an mich selbst.
   Einträge, die erledigt wurden, kann man entweder aus der Liste entfernen oder als erledigt markieren und mit einem Zeitpunkt versehen. So läßt sich nachträglich genau feststellen, was man bereits getan hat (falls einem dieselbe Idee erneut kommt) und wann welche Änderungen gemacht wurden (dies kann im Zusammenhang mit einer Fehlersuche nützlich sein).
   
2. Führe eine Not-To-Do-Liste
   Eine Not-To-Do-Liste dient dazu festzuhalten, was man versucht hat, aber nicht funktionierte, was sich bei der näheren Betrachtung doch nicht so wünschenswert erschien und ähnliches.
   In dieser Liste kann man bei neuen Ideen nachschauen, ob man nicht bereits vorher ähnliches versucht und wieder verworfen hat. Das erspart, denselben Fehler ein zweites Mal zu machen.
   
3. Halte deinen Code sauber und verständlich
   Wer seinen Code ein paar Tage oder Monate später noch verstehen will oder sogar will, daß er von anderen verstanden wird, der sollte folgendes beachten:
   
   1. Sprechende Variablennamen: Variablen sollten so benannt werden, daß man am Namen ihren Zweck erkennen kann. Bei Variablen, die keinen weiteren Zweck haben (z.B. Zähler von Schleifen), kann dies unterlassen werden. Ratsam ist es bei solchen aber wiederum dann, wenn mehrere zugleich verwendet werden (z.B. Schleifen innerhalb von Schleifen).
      Der Übersichtlichkeit wegen, sollten Variablennamen aber auch nicht unnötig lang sein. Meine haben meistens zwischen zehn und 20 Zeichen.
      
   2. Sprechende Funktionsnamen: wie Variablennamen.
      
   3. Kommantare: Kommentare sollte in jeder Datei, bei jeder Funktionen und bei Bedarf (und der ist meistens vorhanden) auch im Code selbst stehen. Sie halten das fest, was man sich bei der Implememtierung gedacht hat.
      
      Dateiweite Kommentare sollten am Anfang der Datei stehen und umreissen, was in dieser Datei zu finden ist, wer den Code erstellt hat und welche von außen kommenden Variablen innerhalb der Datei verwendet werden. Hier kann man auch z.B. vermerken, was wann in dieser Datei von wem geändert wurde (z.B. neue Funktionen, Fehler korrigiert etc.)
      
      Funktionsbezogene Kommentare sollten vor oder am Anfang einer jeden Funktion stehen. Sie beschreiben, was diese Funktion tut, was die Werte bedeuten, mit denen sie aufgerufen wird (Parameter), was die Funktion als Ergebnis zurückliefert sowie welche globalen Variablen sie verwendet (insbesondere falls sie solche ändern sollte - was man übrigens unbedingt vermeiden sollte). Bei komplexen oder selten genutzen Funktionen ist auch ein Beispiel-Code wünschenswert oder ein Verweis darauf, wo die Funktion verwendet wird und entsprechend ein solches Beispiel zu finden ist.
      
      Kommentare im Code selbst sollten wiedergeben, was man sich bei der Implementierung gedacht hat. Als Faustregel gilt hier: Je mehr man über den Code nachdenken musste, desto komplizierter ist er und desto mehr sollte er mit Kommentaren ergänzt werden.
      
      Ich schreibe Kommentare am liebsten während oder unmittelbar nach der Implementierung. Andere lassen sich etwas Zeit. Letzteres hat den Vorteil, daß man nach ein paar Tagen einen Blick auf den Code hat, der eher erkennt, wo Kommentare nötig sind. Der Nachteil ist jedoch, daß Kommentare zu schreiben eine eher ungeliebe Sache ist und deswegen nachträglich gerne "vergessen" wird.
   4. Formatierung: Der Quellcode sollte einheitlich formatiert sein. Und das so, daß man bereits an seiner optischen Struktur möglichst viel über den Aufbau des Codes erfährt.
      Die wichtigste Technik ist dabei das Einrücken von abhängigen Anweisungen gegenüber den Anweisungen, von denen sie abhängig sind. In der Praxis heißt das, dasß z.B. alle Zeilen, die innerhalb einer Schleife liegen, gegenüber der Schleife selbst um eine feste Anzahl Zeichen (z.B. ein Tabulator oder 4 Leerzeichen) nach rechts eingerückt sind. Entsprechend noch weiter eingerückt sind dann Zeilen, die von Anweisungen abhängen, die selbst abhängig von anderen sind.
      Beispiel:
      

       if ( ... ) { Anweisungen.... for ( ..... ) { Anweisungen } } 

      Ebenfalls eine der Übersicht dienende Formatierung ist es, die Gleichzeichen (=) innerhalb eines Blockes (Folge von Anweisungen) an derselben Position auszurichten.
      Beispiel (PHP-Syntax):
      

       if ( $loggedIn ) { $usernameCurrent = getUserName( $id ); $age = 18; $allUsers = getAllUsers(); } 

      Des weiteren sollten nicht mehrere Anweisungen in einer Zeile notiert werden, sollten Zeilen nicht über den sichtbaren Bereich des Editors hinausgehen (besser diese Anweisungen auf mehrere Zeilen verteilen) und ab und an eine Leerzeile um zusammengehörende Anweisungen von anderen abzutrennen, hat auch noch nicht geschadet.
      
4. Vermeide geduldete Nachlässigkeiten
   Viele Compiler oder Interpreter (Laufzeit-Umgebungen) sind recht tolerant gegenüber Nachlässigkeiten des Entwicklers. Sie setzen automatisch Werte für verwendete Variablen oder Konstanten, denen der Entwickler keine Werte zugewiesen hat, sie führen automatisch Typenumwandlungen durch (z.b. Fließkomma- zu Ganzzahl) oder korrigieren gar falsche Notationen zu der ihrer Meinung nach richtigen.
   Kurzum: Sie sind fehlertolerant.
   Das ist schön bei Anwendungsprogrammen, aber trügerisch beim Programmieren. Denn hier ist jede Ungenauigkeit ein potentieller Fehler. Z.B. bedeutet eine undefinierte Variable häufig, daß man einen Schreibfehler eingebracht hat oder eine automatische Typumwandlung bei arithmetischen Operationen, daß man den Rechenvorgang falsch verstanden hat (3 / 2 * 2 ist in Java oder C nämlich nicht 3, sondern 2).
   Deswegen: Zum Entwickeln immer den Compiler oder Interpreter so einstellen, dass Warnungen ausgebenen werden. Und nicht eher ruhen, bis diese beseitigt sind.
   
   Wer es nicht glaubt, der möge einmal einen Schreib- oder Syntaxfehler in einem Java-Programm suchen (aus meinem Erfahrungsraum die Sprache, die dem Entwickler am wenigsten Freiräume und damit Fehlermöglichkeiten gestattet) und dann in einem ActionScript-Script unter Flash (das sich nicht mal beschwert, wenn aufgerufene Funktionen nicht vorhanden sind).
5. Erstelle Sicherheitskopien
   Möglichst regelmäßig und besonders vor großen Änderungen sollte man eine Sicherheitskopie des aktuellen Standes machen.
   Manche Entwicklungsumgebungen unterstützen einen dabei und wer es ganz gewissenhaft machen will, nimmt dafür ein Version-Control-System
   Wer es lieber händisch hat, der kopiert am besten die Verzeichnisse mit dem Quellcode in ein anderes Verzeichnis und macht am besten noch eine Notiz dazu, die kurz den gesicherten Stand beschreibt und wieso man die Sicherung für nötig hielt.
   Gründe, warum es nützlich ist, eine Sicherheitskopie zu haben, gibt es verschiedene. Hauptsächlich sind dies:
   
   • Hat man Änderungen gemacht, die zu einem Fehler führen, der nicht zu beseitigen ist, so kann man auf den letzten Stand vor dem Fehler zurückgehen.
   • Bei der Suche eines neu auftretenden Fehlers kann man verdächtige Stellen mit Ihrer alten Version vergleichen um so zu rekonstruieren, was man geändert hat (Aufpassen, daß man dann die Änderungen im richtigen Code macht und nicht aus Versehen die Sicherheitskopie ruiniert!)
6. Testen des Codes
   Es gibt wahrscheinlich auf der ganzen Welt niemanden, der auf Anhieb fehlerfreien Code produziert. Deswegen sind Fehler auch keine Schande. Aber sie nicht zu suchen oder die böse anzugehen, die einem diese Fehler zeigen und damit deren Verbesserung möglich machen, ist eine!
   Es ist alöso wichtig, seinen Code zu testen. Die Schwierigkeit dabei ist, möglichst viele der zahlreichen Situationen, die bei der Benutzung auftreten können, nachzustellen. Dann das ein Programm auf einem Rechner in den gängigen Situationen funktioniert, heißt bei weitem nicht, daß es auch auf anderen Systemen und unter allen denkbaren Situationen seinen Mann steht.
   Zum Vorgang des Testens selbst, will ich hier nichts weiter sagen. Das ergibt vielleicht eines Tages ein eigenes Kapitel. Wichtig erscheint mir aber noch darauf hinzuweisen, daß man, um einen Fehler sauber zu beseitigen, den Fehler verstehen sollte und nicht so lange den Code ändert, bis es funktioniert. Denn die Freude an einer 'Lösung' vom letzten Typ ist meist nur von kurzer Dauer.
   
7. Wieviel Fehlerbehandlung ist sinnvoll?
   Fehlerbehandlung, d.h. im Code vorherzusehen, wo Fehler auftauchen könnten und entsprechend zu reagieren (alternative Handlung in Erwägung ziehen, Fehlermeldung oder Programm-Abbruch), ist eine sehr zeitraubende und lästige Sache und macht auch nicht gerade den Code übersichtlicher.
   Deswegen ist es hier wichtig abzuwägen, welches Maß an Fehlerbehandlung nötig ist, um den korrekten Ablauf des Programms in den gängigen Fallen zu gewährleisten ohne dabei aber zuviel Zeit auf die Implementierung der Fehlerbehandlung zu verwenden.
   
   Ist man sich bewußt, welche Fehler überhaupt wo auftreten können, dann können einem folgende Kriterien als Entscheidungshilfe dienen:
   
   • Was passiert im schlimmsten Fall, wenn auf den Fehler nicht reagiert wird? Auf keinen Fall darf daraus ein Verlust von Daten oder eine Sicherheitslücke resultieren.
   • Wie wahrscheinlich ist das Auftreten des Fehlers und wie aufwendig ist es, diesen abzufangen?
   • Ist eine Aktion seitens des Benutzers nötig, damit es zu diesem Fehler kommen kann? In diesem Fall kann der Benutzer vielleicht auch zur Behebung des Fehlers beitragen und es bietet sich eine Meldung mit anschließender Wiederholung des Vorganges an.
   • Wird der Fehler bereits auf einer anderen Ebene abgefangen und der Benutzer dort informiert (z.B. vom Betriebssystem oder der Laufzeitumgebung)?
   • Um welche Art Benutzer handelt es sich? Versteht dieser meine Fehlermeldungen? Wie fähig ist er, sich selbst zu helfen?
   
   Auch entschieden werden muß, wie überhaupt reagiert werden soll. Von der Art des Fehlers hängt ab, ob man bei seinem Auftreten einfach im Code etwas überspringt, einen diskreten Eintrag in ein Logfile macht, den Benutzer durch eine Fehlermeldung informiert oder vielleicht auch kommentarlos das Programm beendet.