Wer benötigt schon ein Styleguide?

Die Antwort auf die gestellte Frage ist eigentlich ziemlich simpel. Sie lautet: jeder! Oder besser: jeder, der programmiert. Denn ich spreche hier von Programmierrichtlinien. „Warum, wieso und weshalb?“, fragt ihr euch? „Völliger Blödsinn!“, sagt ihr? Nun, wer meine Argumente hören bzw. lesen möchte, der kann das tun. Alle anderen mögen für immer (zu diesem Thema) schweigen.

 Ich beginne zunächst mit einer kurzen Geschichte.

Sie handelt von einem jungen Prinzen, der auszog, um die Prinzessin G.Halt für sich zu gewinnen. Sie galt als eine der größten und ansehnlichsten Frauen der Welt. Also reiste der Prinz zum Vater der Prinzessin, dem König Schäff, und bat um die Hand seiner Tochter. Doch da die Prinzessin dem König das Liebste auf der Welt war, wollte er den Prinzen zunächst prüfen. Nur wenn er die ihm gestellte Prüfung besteht, wollte der König ihm erlauben, G.Halt mit zu sich zu nehmen. Er trug also dem Prinzen auf, einen Algorithmus zu programmieren oder besorgen, der [… hier weichen die Quellen voneinander ab …]. Um die Aufgabe zu lösen, bekam er 5 Tage Zeit.

Der Prinz dachte lange über das Problem nach, kam aber zu keiner vernünftigen Lösung. Also fragte er seinen Freund und Berater G.Oogle, ob dieser Rat wüsste. Nach einer kurzen Recherche empfahl dieser dem Prinzen in das Land OpenCV zu reisen, ein Land, in welchem viele solcher Probleme schon gelöst worden sind. Dort angekommen musste der Prinz sich weiter durchfragen. Es dauerte nicht lange, da gab man ihm einen Hinweis, wo eventuell ein Algorithmus existiert, der genau das tut, was der Prinz benötigte. Der Algorithmus war schnell gefunden, doch stellte sich heraus, dass er modifiziert werden musste, da die ihm gestellte Aufgabe recht speziell war. Also stellte sich der Prinz der Herausforderung und versuchte, den Algorithmus anzupassen. Sein Problem dabei war, dass er keine passende Dokumentation fand, auch G.Oogle wusste nicht weiter. Kommentare im Quellcode waren kaum vorhanden, Variablennamen nichtssagend und zu allem Überfluss fehlten Umbrüche und Klammern. Das würde eine Menge Arbeit werden und die Zeit drängte.

Ohne Unterbrechung arbeitete der Prinz 8 Stunden am Tag, arbeitete sich in den Code ein und änderte ihn, soweit es nötig war. Am Morgen des fünften Tages hatte er es geschafft. Der Algorithmus war fertig. Der Prinz bat sofort um eine Audienz beim König, welcher nicht sonderlich erfreut war. Dachte er doch, dass es keine Lösung zum Problem gab. Aber er lies den Prinzen vortreten und testete dessen Lösung. Und siehe da, er fand einen Fehler: unter besonderen Bedingungen gab der Algorithmus unsinnige Daten aus. Der Prinz war enttäuscht, schließlich hatte er sein Bestes gegeben.

Doch der Tag war noch nicht vorüber. Ein paar Stunden blieben ihm noch und so setzte er sich erneut hin und suchte den Fehler. Er prüfte den gesamten Quellcode, sah sich seine Änderungen an und da fiel ihm etwas auf. Er hatte an einer besonders unübersichtlichen Stelle Klammern hinzugefügt, welche jedoch an der falschen Stelle wieder geschlossen wurden. Dadurch wurde manchmal eine Funktion aufgerufen, welche die Fehler verursachte. Nachdem er dies sah, korrigierte er umgehend sein Missgeschick und zeigte dem König die neue Lösung.

So sehr der König auch nach einem Fehler suchte, er konnte keinen mehr finden – der Algorithmus lief fehlerfrei. Dem König blieb daher keine Wahl. Er löste sein Versprechen ein und gab G.Halt in des Prinzen Hand. Und wenn sie nicht gefeuert gestorben sind, so debuggen sie noch heute.

Und was ist die Moral von der Geschicht? Nutze fremden Quellcode nicht? Nein, nicht wirklich! Denn eigentlich kennt jeder das Problem: hat man plötzlich fremden Quellcode vor sich und muss diesen verstehen, so ärgert man sich über die Arbeitsweise des Programmierers. Oftmals fehlt es an Kommentaren, Variablennamen lauten „test“ oder „a“, „b“ und „c“, Funktionen „TestTest()“ und die Bedingung einer if-Abfrage erstreckt sich über 5 Zeilen mit jeweils 3 Variablen pro Zeile.

Aber das Beste ist: oftmals ist es der eigene Quellcode, den man nach – sagen wir mal – 6 Monaten erneut bearbeiten muss, nachdem man sich in der Zwischenzeit komplett anderen Themen zugewandt hat. Dann fragt man sich: „Was habe ich damit gemeint?“.

Mal ein kurzes Beispiel, welches ich vor einiger Zeit in der Funktion cvWatershed() der OpenCV 1.0 gefunden habe.

int lab = 0, t;
...
if( t > 0 )
   if( lab == 0 ) lab = t;
   else if( t != lab ) lab = WSHED;

Natürlich ist das Beispiel aus dem Zusammenhang gerissen, aber ihr sollt jetzt auch nicht verstehen, was hier genau passiert. Mir geht es darum, dass dieser Block, der sich tatsächlich über beinahe 80 Zeilen erstreckt, nur eine einzige Kommentarzeile hat. Dazu kommt, dass Variablen wie „t“ nicht aussagekräftig sind und die fehlenden Klammern das Lesen/Verstehen erschweren.

Es gibt aber auch Programmierer, die schreiben fleißig Kommentare. Allerdings sind diese eben sowenig zu gebrauchen, wie keine Kommentare. Hier ein Beispiel:

   int counter = 0;
   counter++;      // erhöht counter um 1

Nachdem ihr nun einiges zu lesen hattet, werdet ihr euch vielleicht fragen, was ich denn nun genau will. Und da ich noch einiges vorhabe, will auch ich langsam zum Ende kommen. Ich reduziere mein Anliegen daher mal auf 3 wichtige Punkte.

1. Schreibt ausreichend, und ausschließlich hilfreiche, Kommentare. Beispielsweise bei einer längeren Schleife was genau in der Schleife passiert oder berechnet wird. Bei Funktionen natürlich das Gleiche.
2. Verwendet aussagekräftige Namen für Variablen, Klassen, Funktionen und so weiter. Beispiel: „whitePixelCounter“ statt „wpc“ ode schlicht „counter“.
3. Programmiert leserlich. Soll heißen: nicht mehrere Anweisungen pro Zeile, verwendet geschweifte Klammern, rückt den Code ein und vermeidet Dateien mit 1000 Codezeilen und 500 Zeichen pro Zeile.

Und denkt immer daran: es könnte euer eigener Quellcode sein, der euch später wieder vorgelegt wird. Und dann wäre es schon unangenehm, wenn man nicht weiß, was da eigentlich passiert, oder? 😉