Allen Planungsproblemchen und Prokrastinationsversuchen zum Trotz ist er tatsächlich fertig geworden: der vielleicht unorthodoxeste (und tollste) Coding-Ratgeber der Dekade, Kathrin Passigs und Johannes Janders „Weniger schlecht programmieren“.

Offizieller Erscheinungstermin ist der 12.12., wir veröffentlichen bereits heute exklusiv das Einstiegskapitel – ein praktischer, „interaktiver“ Selbsttest, der binnen weniger Minuten Auskunft darüber gibt, ob man das Buch auch tatsächlich braucht, also eher dem Lager der suboptimalen Programmierer zuzurechnen ist. Ich tippe mal frech ins Blaue, dass bei einer beträchtlichen Anzahl von Menschen die innere Stimme tendenziell „ja“ sagen wird. ;-) Und übergebe nun an die Autoren:

Antworten Sie ehrlich und ohne lange zu überlegen. Wenn Sie eine Antwortmöglichkeit gar nicht verstehen, machen Sie sich keine Gedanken, sondern wählen eine andere:

Ich schreibe meine Programme …
a) in Notepad.
b) im Browser.
c) in irgendwas anderem.

Wenn etwas nicht funktioniert …
a) poste ich eine Fehlerbeschreibung mit dem Titel „Hilfe!!!“ unter exakter Nennung aller verwendeten Hardwarekomponenten in einem passenden Forum.
b) baue ich viele „print“-Zeilen ein, die mir den Inhalt von Variablen ausgeben.
c) GDB

Zur Versionskontrolle benutze ich …
a) gar nichts. Wenn ich versehentlich was lösche, muss ich es neu schreiben. Deshalb passe ich immer sehr gut auf.
b) SVN.
c) Git oder mercurial.

Ich kommentiere meinen Code …
a) nie, weil ich nicht so viel tippen will.
b) nie, weil ich meinen Code für selbsterklärend halte.
c) nie, weil mein Code selbsterklärend ist.

Wenn ich einen XML-Parser brauche …
a) nehme ich mir ein Wochenende Zeit und schreibe einen, wie schwer kann das schon sein.
b) Ich brauche keinen XML-Parser.
c) Ich lese die Wikipedia-Einträge zu SAX- und DOM-Parsern durch, sehe mir verschiedene Bibliotheken und deren Bindings an meine verwendete Programmiersprache an, wäge ihre Vor- und Nachteile ab und finde heraus, ob es eine lebendige Community dazu gibt.

Um E-Mail-Adressen zu validieren …
a) schreibe ich schnell zwei Zeilen hin, die ich an meiner eigenen Mailadresse überprüfe.
b) teste ich, ob ein @-Zeichen enthalten ist.
c) google ich nach einer Regular Expression, auf deren Korrektheit sich namhafte Projekte verlassen.

Mein Code und das Licht der Öffentlichkeit:
a) Ich halte meinen Code geheimer als ein Messie seine Wohnung.
b) Wenn jemand Code von mir sieht, der schon ein halbes Jahr alt ist, dann ist mir das ein bisschen peinlich.
c) Mein Code ist Teil des Linux-Kernels.

Ich teste meinen Code …
a) gar nicht. Wenn etwas nicht mehr funktioniert, merke ich das schon früher oder später.
b) nach jeder Änderung an meinem Code.
c) gar nicht. Nach jeder Änderung an meinem Code prüfen automatisierte Unit-Tests, ob noch alles funktioniert.

Wie sieht ein geeignetes Datumsspeicherformat aus?
a) Wie schon, „T.M.JJ“ natürlich!
b) Die vergangenen Sekunden seit 00:00 Uhr Koordinierter Weltzeit am 1. Januar 1970, wobei Schaltsekunden nicht mitgezählt werden, gespeichert in einem 64-Bit-Integer.
c) ISO 8601.

Optimierung …
a) ist mir egal.
b) betreibe ich so lange, bis das Programm auf meinem 2,4 GHz Core 2 Duo mit 256MB 2nd Level Cache in 43.3485 Taktzyklen durch ist.
c) ist mir so lange egal, wie die User Experience nicht durch Wartezeit beeinträchtigt wird.

Alle anderen Programmierer …
a) sind besser als ich.
b) sind schlechter als ich.
c) Mal so, mal so.

Ich überarbeite meinen Code …
a) nie, ich nehme mir aber hin und wieder vor, alles noch mal neu und besser zu schreiben.
b) in einem winzigen Schritt nach dem anderen, wenn ich gerade viel Zeit habe.
c) in einem winzigen Schritt nach dem anderen, auch wenn ich gerade wenig Zeit habe.

Überschlagen Sie jetzt grob, ob Sie mehr als die Hälfte der Fragen mit a) oder b) beantwortet haben. Wenn ja, dann ist „Weniger schlecht programmieren“ für Sie geschrieben.

Haben Sie mehr als die Hälfte der Fragen mit c) beantwortet, dann lachen Sie bitte nicht höhnisch, sondern gehen weiter und programmieren Linux-Kerneltreiber. Oder was Sie sonst so tun.