2018-09-02 digital life Kommentare Make every comment count! Vorgestern habe ich mir etwas ratlos ueberlegt, was ich denn lesen koennte. Mein letztes Buch war ausgelesen. Einen naechsten Kandidaten hatte ich noch nicht im Auge. Manchmal ist klar, was ich als naechstes lesen will, ab und an stehe ich aber auch vor dem Regal und bin unentschieden. So diesmal. Eigentlich waere mir schon wieder nach einem Roman, einer Fantasiegeschichte gewesen, nach so vielen Sachbuechern, andererseits war es auch schoen, diese Sachbuecher zu lesen, so dass ich gleich noch eines nachschieben koennte. Am Ende habe ich mich entschieden seit Langem mal wieder ein Computerbuch zu lesen. Ich habe eine ganze Menge alter Computerbuecher im Regal, die ich nach und nach lese. Eines davon ist das nun ausgewaehlte ``Practical C Programming'' von Steve Qualline. Das Buch ist vom Anfang der 90er Jahre (was bei meiner Computerliteratur durchaus eine relevante Information ist). Dieses O'Reilly-Buch mit dem auffaelligen Kuh-Cover habe ich zum ersten Mal in Karlsruhe gesehen, bei einem Besuch bei der Entro- pia (vielleicht 2010). Dort stand es in den Clubraeumen im Buecherregal. Damals schon dachte ich, dass das ein fuer mich sicher interessantes Buch sein wuerde. Ein paar Jahre spaeter (2013) habe ich es, wiederum in Karlsruhe, bei einer Bibliothek- sentruempelungsaktion ergattert. (Es ist so, dass die Bibliothek- en ueblicherweise die Computerbuecher aus ihren Regalen entfer- nen, die mich interessieren.) Jetzt, 2018, lese ich es -- allerd- ings nicht in Karlsruhe. Ich mag solche Hintergrundgeschichten und zeitlichen Dimensionen, die an einzelnen Buechern haengen. (Auch darum mag ich physische Buecher: Sie haben Geschichten.) Ich habe mit dem Buch begonnen. Das Inhaltsverzeichnis liest sich schonmal richtig gut: Ein Rundumschlag zur C-Programmierung. Ein bisschen wie ``The Practice of Programming'' oder auch ``Clean Code'', bloss primaer auf C fokussiert. Im zweiten Absatz des Vorworts: Style is emphasized. Creating a good program requires more than just typing in code. It is an art where writ- ing and programming skills blend themselves together to form a masterpiece. A well-written program not only functions correctly, but is simple and easy to under- stand. Da fuehle ich mich gleich aufgehoben. :-) Dann, in Kapitel 1, ein wunderbar knapper und verstaendlicher Ue- berblick, wie Programmieren, Kompilieren, Linken und Ausfuehren bei C zusammenhaengen. Meist wird dieses Wissen hinter einer IDE versteckt. Hier wird es verstaendlich offengelegt. Schoen! Schon im zweiten Kapitel die interessantesten Inhalte: It may seem backward to discuss style before we know how to program, but style is the most important part of programming. Wie recht er hat! Style is the most important part of program- ming! So ist es ... auch wenn viele Programmierer und Program- mierdozenten das leider noch nicht verstanden haben. Und dann bringt er eine der ganz wichtigen Einsichten, zu denen ein Programmierer kommen sollte: Ideally, a program serves two purposes: first, it presents the computer with a set of instructions, and second, it provides the programmer with a clear, easy- to-read description of what the program does. (Dieses ``ideally'' sollte allerdings nicht als Utopie sondern als konkretes Ziel verstanden werden.) Ich lese all dies und schwebe auf Wolken ... dann aber, im fol- genden Absatz, stuerze ich ab. Er beginnt mit: Program 1-1 contains a claring error. Ich schaue mir also das Programm 1-1 an: #include main() { (void) printf("Hello World\n"); return (0); } Nun ... hmm ... einen herausstechenden Fehler kann ich nicht erk- ennen. Nun gut, der int-Returnwert von main() fehlt, aber ich weiss, dass der nicht noetig ist, weil int der Default ist. Dann der void-Cast des Returnwerts von printf() -- kein Fehler ... nach meiner Ansicht zwar nicht optimal (weil zuviel Noise fuer zu wenig Information oder Mehrwert), aber in manchen Programmierkul- turen durchaus so ueblich. Ebenso die geklammerte Null nach dem Return, was nicht noetig ist ... und falls man eine Funktion- saufrufsillusion beim `return' *Statement* erzeugen wollen wuerde, sollte man den Space vor der Klammer weglassen. (Aber besser keine falschen Illusionen erzeugen, denn `return' ist keine Funktion.) -- Alles Kleinigkeiten, die von unterschiedli- chen C-Programmier-Communities unterschiedlich bewertet werden. Jedenfalls nichts was zu diesem folgenden Satz im Buch passen wuerde: It is an error that many programmers still make, and one that causes more trouble than any other problem. Ich hatte absolut keine Ahnung was er meinte. Wenn ich dieses Beispielprogramm aus meiner Sicht perfektionieren sollte, dann saehe es so aus: #include int main() { printf("Hello World\n"); return 0; } (Die Version im K&R laesst den Return-Type `int' und das `return'-Statement weg.) Wo also ist der herausragende Fehler, der so viele Probleme verursachen wuerde? Die Aufloesung kommt im folgenden Satz: The program contains no comments. Und dann wird die ``verbesserte'' Version praesentiert -- und ich befinde mich im freien Fall: /******************************************************** * hello -- program to print out "Hello World", * * Not an especially earth-shattering program. * * * * Author: Steve Qaulline * * * * Purpose: Demonstration of a simple program * * * * Usage: * * Run the program and the message appears * ********************************************************/ #include main() { /* Tell the world hello */ (void) printf("Hello World\n"); return (0); } Was fuer ein Desaster! So viel Gutes auf den ersten Seiten. So viel Hoffnungsvolles. Und dann so eine desastroese Aussage und so ein desastroeses Beispiel! Da wird mir wieder richtig bewusst, warum Kernighan und Co. so- viel bessere Buecher zu diesen Themen geschrieben haben: Sie ha- ben stets Beispiele aus der Praxis verwendet. Hier dagegen wurde ganz klar konstruiert. Kein Programmierer, der klar denken kann, wuerde ein Hello-World-Programm kommentieren. Man kann viel- leicht noch darueber diskutieren, ob man kurze Programme ue- berhaupt kommentieren sollte, aber ein Hello-World-Programm zu kommentieren ist schlichtweg daneben. Der einzige ueberhaupt sinnvolle Kommentar bei einem Hello-World-Programm ist, dass es sich bei ihm um ein Hello-World-Programm handelt. ... Genauso wie der einzige sinnvolle Kommentar bei der Verwendung von Duff's Device der Hinweis ist, dass es sich um Duff's Device handelt. (Nicht dass man Duff's Device einsetzen sollte, es liefert mir hier nur ein bequemes Beispiel. ... und dieser noetige Nachsatz demonstriert schon, warum man seine Beispiele gut waehlen sollte.) Jedes Beispiel sollte ein Leitbild fuer Produktivcode sein ... denn Menschen immitieren was sie sehen. Leider ist Quallines Verstaendnis von Kommentaren und deren Bez- iehung zur Lesbarkeit von Code falsch. In Folge dieses falschen Verstaendnisses macht er schaedliche Aussagen und demonstriert ein fuer Anfaenger schaedliches Beispiel. Ich finde das irri- tierend, weil er mit seinen sonstigen Aussagen durchaus zeigt, dass er verstanden hat, worauf es ankommt: Your program should read like an essay. It should be as clear and easy to understand as possible. Good program- ming comes from experience and practice. The style described in the following pages is the result of many years of programming experience. It can be used as a starting point for developing your own style. These are not rules, only suggestions. The only rule is: make your program as clear, concise and simple as possible. Die Grundeinsichten sind also vorhanden, bloss fehlt es hier und da an dem was einen Meister ausmacht. Er macht Schritte, aber manchmal sind sie zu kurz. Er macht Schritte, aber nicht immer konsequent genug. Wenn ich mir vorstelle, wie Kernighan dieses Buch Anfang der 90er Jahre angeschaut haben muss, in dem Bewusstsein, dass er (gemein- sam mit Plauger) diese Themen bereits 1974 adressiert hatte, aber scheinbar nicht genug davon bei den Programmierern angekommen ist. Man bedenke nur folgende Lesson in Kernigan und Plaugers Buch in Verbindung mit obigem ``verbessertem'' Code! Don't just echo the code with comments -- make every comment count. Da ist es doch kein Wunder, dass Kernighan (diesmal mit Pike zusammen) 1999 ``The Practice of Programming'' schreiben musste. Im Kern ist es eine Neuauflage von ``The Elements of Programming Style''. Daneben kann man es sicher auch als (korrigierende) Reaktion auf halbgute Buecher wie ``Practical C Programming'' verstehen. Es ist sehr schade, dass ``The Practice of Programming'' nie wirklich bekannt geworden ist. Stattdessen wurde diese Rolle dann von dem ein paar Jahre spaeter geschriebenen (mehr dem Zeitgeist entsprechenden) ``Clean Code'' uebernommen, welches in meinen Au- gen inhaltlich deutlich schwaecher ist. Aber nochmal zurueck zu Quallines Fokus auf Kommentare. Seine Grundziele sind ja nicht falsch, bloss seine Bewertung der Mit- tel, um das Ziel zu erreichen, sind es. Ich war auch einmal an diesem Punkt. Das relevante Aha-Erlebnis habe ich einem Zusatzkurs im Studium zu verdanken. Es war ein Kurs zur Aspek- torientierten Programmierung in Java. Auch damals schon hatte ich mit Java wenig am Hut, konzeptionell war diese aspektorientierte Idee aber sehr interessant. Zudem war der externe Dozent gut ... also inhatlich gut. (Es war ein Wahlfach und ich nahm daraus eine meiner schlechten Noten im Studium mit. Warum, weiss ich eigentlich bis heute noch nicht. Es gab keine schriftlichen Pruefungen. Die praktischen Uebungen haben mich wenig interes- siert, weil ich nicht Java-Programmieren sondern Konzepte lernen wollte, somit bin ich da regelmaessig frueh gegangen. In den Vor- lesungen habe ich aber aktiv mitgemacht und mich oft gemeldet -- darauf wollte er seine Note aufbauen -- scheinbar hat er da etwas nicht recht auf die Reihe gebracht. Auf seine Frage, welche muendliche Note ich mir denn selbst geben wuerde, habe ich, fuer mich typisch, defensiv angesetzt. Er hat mich dann noch tiefer verortet. Mit meinem heutigen Wissen muss ich zu dem Ergebnis kommen, dass die Note voll daneben war. Ich hab damals mein Gefuehl, dass die Note zu schlecht sei, einfach ertragen, habe noch nicht einmal seine Entscheidung in Frage gestellt. -- Tja, so passiert es einem, wenn man eher der stillere, unsichere, in- trovertierte Typ ist.) Inhaltich war der Kurs aber einer der Highlights meines FH-Studiums. Insofern war er die schlechte Note vollkommen wert! An einem Termin hat er den Kurs gefragt, welche Moeglichkeiten es gaebe, den Sinn von Code zu transportieren. Er wollte die wichtigsten Moeglichkeiten zuerst hoeren. Ich habe mich als er- ster gemeldet (soviel zur Mitarbeit ;-) ) und ``Kommentare'' vor- geschlagen ... ganz nach Qualline-Art. Seine Reaktion darauf war die vermutlich wichtigste Lektion zu Style beim Programmieren, die ich vom Studium mitbekommen habe. Wirklich verstanden habe ich sie erst in den Jahren danach. Dass ich aber immer wieder darueber nachgedacht habe, lag daran, dass ich mir damals sicher war, richtig zu liegen, aber dennoch eines Besseren belehrt wurde. Er meinte, dass es etwas Wertvolleres im Code gaebe als Kommentare und dass das die Bezeichner waeren. -- Wie Recht er hatte! Viele Jahre spaeter habe ich dann selber darueber geschrieben. [0] ``Practical C Programming'' ist eine wunderbare Diskus- sionsgrundlage fuer ein Seminar ueber Programmierstil. Man sollte das Buch aber fernhalten von Personen, die moeglicherweise unreflektiert glauben was sie lesen. [0] http://marmaro.de/apov/txt/2016-01-21_gute-bezeichner.txt http://marmaro.de/apov/ markus schnalke