Coding-Horror

In meinen (fast) täglichen Diskussionen höre ich immer wieder die Aussage “Über Programmierstil lässt sich nicht streiten”. Dem möchte ich hier gänzlich widersprechen. Man kann darüber vortrefflich streiten. Außerdem behaupte ich auch noch dreist, dass diese Aussagen von Programmierern getroffen werden, die entweder zu faul, zu überfordert oder extrem eingebildet sind. Ich habe auch noch nie erlebt, dass ein wirklich guter Programmierer einen solchen Satz von sich gegeben hat. Denn ein solcher Satz ist Zeichen von mangelnder Selbstreflexion.

Beim Programmieren reihen wir nicht nach Schema-F irgendwelche Zeichen aneinander. Vielmehr ist es eine Kunst. Ein schöpferischer Akt. Es gilt etwas aus dem Nichts zu erschaffen. Öffnen wir eine neue Datei, so sitzen wir wie ein Maler vor einer weißen Leinwand und sind dann nur unserer eigenen Kreativität und Disziplin unterworfen. Aber welche Kunst kommt ohne Selbstreflexion aus?

Nun zum eigentlichen Thema dieses Beitrags mit dem Schönen und von google beängstigenderweise noch nicht indizierten (!) Titel: Erfahrungsgrätsche:

Wenn wir in einem größeren Projekt arbeiten, so ist es von Natur aus gegeben das junge und unerfahrene Programmierer mit den “alten Hasen” zusammenarbeiten. Oder Kollegen verlassen das Projekt und neue Kollegen kommen hinzu. Was immer einen Erfahrungsverlust bedeutet aber auch einen frischen Wind ins Team bringt. Allen ist (hoffentlich) gemein, dass sie das Projekt erfolgreich beenden möchten. Das schwächste Glied in der Kette ist der Neueinsteiger. Der entweder noch keine Berufserfahrung hat oder sich neu in einem Projekt einarbeitet. Kann man diese “Erfahrungsgrätsche” überbrücken? Ja – ich denke die Einstiegshürde kann man erheblich niedriger gestalten. Dies können aber nur die erfahrenen Programmierer tun. Diese sind hier in die Pflicht zu nehmen. Wie kann das geschehen? Zum einen einmal über die Dokumentation. Darüber brauche ich wohl kein Wort zu verlieren. Zum Anderen aber auch über strukturierten und vor allen Dingen einfachen Quellcode. Der – nur nochmal beiläufig erwähnt – kommentiert sein muss. Die aktuellste Dokumentation ist und bleibt nun einmal der Quellcode selbst.

Was bedeutet denn nun “einfacher Quellcode”. Ist es die Anzahl der Operationen pro Zeile? Die Anzahl der Bedingungen innerhalb einer Abfrage? Ist es einfache Eleganz oder gar die geschickte Ausnutzung der gegebenen Möglichkeiten? Nein – und doch Ja. Hier kommt es auf die Definitionen der einzelnen Begriffe an. Ich für meinen Teil definiere “einfachen Quellcode” als Gehirn gerecht und einfach klassifizierbar. Was auch bedeutet, das der Quellcode nicht den Erfahrungen aus unserem alltäglichen Leben widerspricht.

Was meine ich mit dem ersten Punkt: “Gehirn gerecht klassifizierbar”. Nehmen wir einmal die folgende C/C++ Methode:

Sie ist sehr elegant und nutzt auch einige spezielle Spracheigenschaften aus. Aber ist diese Methode einfach zu verstehen? Wie lange braucht man um zu verstehen was sie tut? Viel wichtiger ist jedoch die Frage: Würde sich ein Anfänger die Zeit nehmen diese im Projektalltag zu verstehen? Wenn ja, wie hoch ist die Wahrscheinlichkeit das ein Anfänger diese Methode auch richtig interpretiert? Mal Hand aufs Herz wie lange brauchtest Du um zu verstehen was die Methode macht? Oder hast Du auch einfach weiter gelesen und es erst gar nicht versucht, weil diese auf den ersten Blick zu komplex erscheint? Genau darin liegt das Problem.

Was macht diese Methode nicht einfach für das Gehirn klassifizierbar? Zum Beispiel die Tatsache das in der äußeren Klammer zwei Größenvergleiche voneinander subtrahiert werden. Dies hat das Gehirn nicht gelernt. Im Alltag gibt es keine Entsprechung dafür. Wie zum Beispiel: ‘Wenn das Auto schneller ist als 100KMh’ subtrahieren wir davon ‘Wenn die Anzahl der Fahrspuren kleiner Drei ist’. In diesem Beispiel knarzt es gehörig im Gebälk unserer Synapsen. Das Gehirn meldet bereitwillig: Das ist totaler Unfug!
Nun ist es aber so, das ein solcher Unfug einfach in jeder Programmiersprache umgesetzt werden kann. Das ist ein schönes Beispiel dafür, das völlig dem Prinzip des “Gehirn gerechten Klassifizierens” widerspricht.

Nun zum Punkt Zwei: “Quellcode soll den Erfahrungen des alltäglichen Lebens nicht widersprechen”.

Im ersten Punkt hat sich bereits ein Beispiel gefunden, was den Erfahrungen des alltäglichen Lebens widerspricht. Die Subtraktion zweier Vergleiche. Dieses schon ziemlich komplexe Beispiel lässt sich aber noch viel weiter runter brechen. Hat z.B. irgendjemand in der Fahrschule einen Satz gehört wie: “Wenn 80KMh kleiner ist als Ihre aktuelle Geschwindigkeit, dann müssen sie den Sicherheitsabstand erhöhen”. Oder hat auf Deinem Giro-Konto Antrag etwa folgendes gestanden: “Wenn 0 größer ist als Ihr aktueller Kontostand, berechnen wir Zinsen”. Ganz sicher nicht! Das widerspricht einfach unserem Alltag und unserer Lernerfahrung. In jeder Programmiersprache kann man aber genau so etwas problemlos formulieren:

Dies hat zur Folge, dass beim überfliegen des Quellcodes entweder Teile einfach falsch wahr genommen und somit falsch Klassifiziert werden oder viel wahrscheinlicher, dass dem Leser diese merkwürdige ungewohnte Struktur ins Auge fällt. Er muss sie dreimal lesen, bevor er sie verinnerlicht hat. Die Augen müssen mehrfach hin und her springen. Dies unterbricht den Lesefluss erheblich. Wobei die andere Formulierung von Oben nach Unten flüssig und ohne Unterbrechung gelesen werden kann:

Deshalb plädiere ich dafür, das Konstrukte beim Abbilden in einer Programmiersprache so weit wie möglich unserer alltäglichen Erfahrung und auch unserem Sprachdenken entsprechen. Die vorausgegangenen Beispiele lassen sich einfach in ein sprachliches Konstrukt Umformen: “Wenn die Geschwindigkeit größer als 80KHm ist, dann wird der Sicherheitsabstand erhöht” oder “Wenn Ihr Kontostand negativ ist, werden Zinsen berechnet”. Somit kann man große Teile Quellcode fast lesen wie seine Muttersprache. Aber versucht dies einmal mit einem meiner Quälkot-Lieblinge. Eure Versuche sind als Kommentare herzlich Willkommen:

Nun am Fuße dieses doch etwas länger geratenen Artikels möchte ich nochmal die erste Methode aufgreifen. Ich vermute das viele immer noch nicht wissen was diese tut, weil sie sich nicht die Zeit genommen haben sie zu verstehen. Ich habe diese Methode umgeschrieben um einmal zu demonstrieren, wie eine Umsetzung aussehen könnte, die diesem Artikel Rechnung trägt:

Wie groß die Zeitersparnis ist, könnt Ihr daran selbst beurteilen. Hier wurde auch lediglich eine Methode betrachtet die ursprünglich nur eine Zeile umfasste. Wie sieht es aus, wenn die Ursprungsmethode 30 Zeilen gleicher Komplexität kapselt?

Als Schlussbemerkung möchte ich noch einmal auf das Gleichnis vom Künstler und dem Programmierer zurückkommen. Nachdem wir unsere eigene kleine weiße Leinwand mit unserem “Kunstwerk” kreiert haben, liegt es im Auge des Betrachters ob er dieses Kunstwerk auch versteht. Experten dieser Kunst können vielleicht die Schönheit und Eleganz in ihrer komplexen Vielfalt erkennen. So in der ersten aber auch in der zweiten Methode. Aber gelingt es auch dem Laien dieser Kunst? Einem Anfänger?
Betrachten wir einmal die Bilder von einem der berühmtesten Maler: Pablo Picasso. Vermag ein Laie die Einzigartigkeit dieser Kunst zu verstehen? Warum ist die Welt von diesen Werken so begeistert, wo doch die Nachbarin von nebenan – in unseren Augen – gleichwertiges malt? Betrachten wir aber Bilder von Michelangelo oder die Mona Lisa von Leonardo da Vinci, da wird selbst einem Kunstbanausen klar, dass es sich um ein echtes und einmaliges Kunstwerk von erster Güte, Ausdruck und Qualität handelt.

Die Frage ist nun: Möchte ich ein Pablo Picasso oder eher ein Michelangelo sein?

Dieser Eintrag wurde am Dienstag, 23. Juni 2009 um 11:13 am erstellt und ist abgelegt unter Readme.txt. Mit dem RSS 2.0 Feed kannst du den Antworten zu diesem Artikel folgen. Du kannst eine Antwort hinterlassen, oder einen Trackback von deiner eigenen Seite senden.