"Wir werden nackt, nass und hungrig geboren, und dann wird alles noch schlimmer."
(Aus China)

Codierung

Für die Codierung gibt es unzählige alte Tipps, die auf gewisse Art sicherlich immer noch ihre Gültigkeit haben. Oft wird über all die Probleme mit IDEs (Entwicklungsumgebungen), APIs (Programmierschnittstellen) und Tools vergessen, dass auch noch echter Code getippt werden muss. Ich habe mir 2003 auf der CeBIT mehrfach von Studenten anhören müssen, dass an den Unis heute sehr viel über Methodik und Systematik gelehrt wird - aber viel zu wenig über das eigentliche Coding. Dies müsse man sich mühevoll innerhalb der Projekte von den Veteranen abschauen.

Hier einfach mal ein paar Überschriften aus [B12]:

   "Use descriptive names for globals, short names for locals"
     (dt.: "Benutze beschreibende Namen für globale Variablen, kurze Namen für lokale Variablen")

   "Use active names for functions"
     (dt.: "Benutze aktive Namen für Funktionen")

   "Indent to show structure"
     (dt.: "Einrücken, um die Struktur zu zeigen")

   "Break up complex expressions"
     (dt.: "Komplexe Ausdrücke aufbrechen")

   "Give names to magic numbers"
     (dt.: "Benenne Zahlen wie Konstanten, Arraygrößen, Indizes, etc.")

   "Don´t comment bad code, rewrite it"
     (dt.: "Schlechten Code nicht kommentieren, sondern neu schreiben")

Hier zwei Anti-Beispiele für Code aus oben genanntem Buch (natürlich in C, ist schließlich von Kernighan):
   *x+=(*xp=(2*k<(n-m)?c[k+1):d[k--]));
   child=(!LC&&!RC)?0:(!LC?RC:LC);

Wir haben im Februar 2002 bei einem Review-Auftrag eines fremden VisualBasic-Programms tatsächlich folgenden Code gefunden:

   ' Update the caption and fill in the list of options.
   If CurrentUser = "xxx" Then mde_kopieren.Visible = False
   If CurrentUser <> "xxx" Then mde_kopieren.Visible = False
   If CurrentUser = "yyy" Then Label1.Caption = ...

Was sagen uns die beiden ersten Code-Zeilen? Und die Namen der Benutzer waren wirklich hart codiert! Und "Label1" ist doch auch selbst erklärend, oder? Die Controls nicht zu benennen ist übrigens üble gängige Praxis in VB. Und wozu soll eigentlich der Kommentar gut sein? Ich meine, es sollte vor jedem Softwarehaus einen Baum geben, an dem man solche Codierer aufhängen kann.

Ich kann auch die Bücher [B15] und [B1] sehr empfehlen, wenn sich jemand mit Codierung beschäftigen möchte. Gerade die eigentliche Programmierung hat ganz viel mit Best Practices (dt.: Beste Praktiken) und persönlicher Erfahrung zu tun. Es ist ein wenig wie in dem Film "Matrix": man muss lernen den Code dahinter zu sehen. Dazu sollte man sich ruhig auch mal mit alten Schinken wie [B27] beschäftigen, damit man zumindest mal weiß, was eine verkettete Liste ist. Dies schadet auch dann nicht, wenn man sich nur noch mit Collections in Java rumschlägt. Und wer weiß bei einem "Stack Trace" denn heute wirklich noch, was da eigentlich genau mit "Stack" gemeint ist?

Zur Optimierung von Code sage ich nur:

   Die erste Regel der Optimierung heißt: "tu's nicht"
   Die zweite Regel der Optimierung heißt: "wenn doch, tu's erst am Schluss"

Zu Assembler-Zeiten wurden noch die Taktzyklen gezählt, um die Schleifen zu optimieren, aber heute gibt es diese Art von Problem zum Glück so gut wie nicht mehr. Auch die Optimierung hinsichtlich des Speicherplatzes ist in Zeiten von Mega- und Gigabytes ziemlich wurscht - schließlich ist heute jeder Virus größer als früher eine ganze Textverarbeitung!

Am Anfang der Implementierung sollten sich die Entwickler zusammensetzen und über die Verantwortung an den Schnittstellen diskutieren - ja, dieses Thema ist tatsächlich immer wieder für eine Diskussion gut! Auch wenn vielleicht bereits im Kick-Off-Meeting die Code-Konventionen für das Projekt vorgestellt wurden, so lohnt es sich, die Codierer hier noch einmal ins Gebet zu nehmen. Ist nun der Aufrufer einer Funktion für die Korrektheit der Argumente verantwortlich oder muss die Funktion ihre Parameter noch mal prüfen? Gemäß dem berühmten "Design By Contract" (DBC, dt.: Entwurf gemäß Vertrag; wurde zuerst von Bertrand Meyer entwickelt und in die Programmiersprache Eiffel eingebaut) muss der Aufrufer eine ganz bestimmte Situation vor Aufruf garantieren (Precondition) während die Funktion eine ganz bestimmte Situation nach dem Aufruf garantiert (Postcondition) - das ist der Vertrag, den Funktion und Aufrufer schließen. Das verdammt Dumme daran ist nur, dass außer Eiffel keine andere Sprache und daher auch kein gängiger Compiler in der Lage ist, diesen Vertrag zu prüfen. DBC unterliegt also der Disziplin der Codierer - und das ist immer schlecht! Daher kann ich nur dazu raten, die Precondition am Anfang in der Funktion noch mal zu prüfen und die Parameter zu plausibilisieren. Dies hat natürlich auch Auswirkungen auf die Schnittstellentests. Natürlich muss auch das Error Handling (dt.: die Fehlerbehandlung) im Code darauf abgestimmt sein: was macht also die Funktion, wenn sie einen Vertragsbruch feststellt? Sowohl die Parameterprüfung als auch die Fehlerbehandlung unterliegen natürlich auch der Disziplin der Codierer, was immer noch schlecht ist, aber es handelt sich dabei immerhin um eine - sagen wir mal - "schlechte Zusatzsicherung".

Im XP (Extreme Programming) gibt es den phantastischen Ansatz des "Pair Programming", den man eigentlich in allen Projekten zur Pflicht machen sollte. Dabei codiert ein Teammitglied einen Anwendungsfall und gleichzeitig ein anderes Teammitglied die zugehörigen Testfälle (deshalb auch "paarweise Programmierung"). Sind beide fertig, so tauschen und sichten sie die Quellen. Nach einigen Diskussionen und Änderungen kommt es dann zum Testlauf. So können Sie gewährleisten, dass Ihr Code ziemlich frei von Fehlern ist, bevor Sie die nächste Iteration beginnen.

Heutzutage sollte der Einsatz von Quellverwaltungs-/Versionierungs-Tool (z.B. Microsoft Visual Source Safe) selbstverständlich sein. Dies sorgt einerseits für saubere Teamarbeit, weil jeder seine Änderungen erst lokal testen kann, bevor er sie den Kollegen zumutet. Andererseits können Änderungen verfolgt werden: Wenn Sie ein neues Build ziehen, labeln Sie einfach alle Quellen und können dann jederzeit wieder auf den Quellstand dieser Version zurück, um Fehler zu reproduzieren und zu suchen.

Während der Implementierungsphase sollten die Tools nur im absoluten Notfall gewechselt werden, weil dadurch in der Regel eine große Unbekannte in die Kalkulation des Projektverlaufs kommt. Das gilt auch für neue Versionen der Tools oder im schlimmsten Fall gar für den Wechsel der technischen Plattform. Dies bedarf schon sehr kräftiger Gründe. Bei Problemen mit Tools sollte man auch nie darauf hoffen, dass diese mit neuen Versionen gelöst werden. Da ist es besser, wenn man unbekannte Tools vor Entwicklungsstart gründlich evaluiert.