debianforum.de

2018-09-02_kommentare.roff

SNIPPET_TEXT:

1. ._D "2018-09-02
2. ._C "digital life
3. ._T "Kommentare
4. ._S "Make every comment count!
5. ._1
6.  
7. Vorgestern habe ich mir etwas ratlos ueberlegt, was ich
8. denn lesen koennte. Mein letztes Buch war ausgelesen. Einen
9. naechsten Kandidaten hatte ich noch nicht im Auge. Manchmal
10. ist klar, was ich als naechstes lesen will, ab und an stehe
11. ich aber auch vor dem Regal und bin unentschieden. So
12. diesmal. Eigentlich waere mir schon wieder nach einem Roman,
13. einer Fantasiegeschichte gewesen, nach so vielen Sachbuechern,
14. andererseits war es auch schoen, diese Sachbuecher zu lesen,
15. so dass ich gleich noch eines nachschieben koennte. Am Ende
16. habe ich mich entschieden seit Langem mal wieder ein
17. Computerbuch zu lesen. Ich habe eine ganze Menge alter
18. Computerbuecher im Regal, die ich nach und nach lese.
19. Eines davon ist das nun ausgewaehlte ``Practical C
20. Programming'' von Steve Qualline. Das Buch ist vom Anfang der
21. 90er Jahre (was bei meiner Computerliteratur durchaus eine
22. relevante Information ist).
23.  
24. Dieses O'Reilly-Buch mit dem auffaelligen Kuh-Cover habe
25. ich zum ersten Mal in Karlsruhe gesehen, bei einem Besuch bei
26. der Entropia (vielleicht 2010). Dort stand es in den Clubraeumen
27. im Buecherregal. Damals schon dachte ich, dass das ein fuer mich
28. sicher interessantes Buch sein wuerde. Ein paar Jahre spaeter
29. (2013) habe ich es, wiederum in Karlsruhe, bei einer
30. Bibliotheksentruempelungsaktion ergattert. (Es ist so,
31. dass die Bibliotheken ueblicherweise die Computerbuecher aus
32. ihren Regalen entfernen, die mich interessieren.) Jetzt, 2018,
33. lese ich es -- allerdings nicht in Karlsruhe. Ich mag solche
34. Hintergrundgeschichten und zeitlichen Dimensionen, die an
35. einzelnen Buechern haengen. (Auch darum mag ich physische
36. Buecher: Sie haben Geschichten.)
37.  
38.  
39. Ich habe mit dem Buch begonnen. Das Inhaltsverzeichnis liest
40. sich schonmal richtig gut: Ein Rundumschlag zur C-Programmierung.
41. Ein bisschen wie ``The Practice of Programming'' oder auch
42. ``Clean Code'', bloss primaer auf C fokussiert.
43.  
44. Im zweiten Absatz des Vorworts:
45.  
46. .QS
47. Style is emphasized. Creating a good program requires more
48. than just typing in code. It is an art where writing and
49. programming skills blend themselves together to form a
50. masterpiece. A well-written program not only functions
51. correctly, but is simple and easy to understand.
52. .QE
53.  
54. Da fuehle ich mich gleich aufgehoben. :-)
55.  
56. Dann, in Kapitel 1, ein wunderbar knapper und verstaendlicher
57. Ueberblick, wie Programmieren, Kompilieren, Linken und
58. Ausfuehren bei C zusammenhaengen. Meist wird dieses Wissen
59. hinter einer IDE versteckt. Hier wird es verstaendlich
60. offengelegt. Schoen!
61.  
62. Schon im zweiten Kapitel die interessantesten Inhalte:
63.  
64. .QS
65. It may seem backward to discuss style before we know how to
66. program, but style is the most important part of
67. programming.
68. .QE
69.  
70. Wie recht er hat! Style is the most important part of
71. programming! So ist es ... auch wenn viele Programmierer und
72. Programmierdozenten das leider noch nicht verstanden haben.
73.  
74. Und dann bringt er eine der ganz wichtigen Einsichten, zu
75. denen ein Programmierer kommen sollte:
76.  
77. .QS
78. Ideally, a program serves two purposes: first, it presents
79. the computer with a set of instructions, and second, it
80. provides the programmer with a clear, easy-to-read
81. description of what the program does.
82. .QE
83.  
84. (Dieses ``ideally'' sollte allerdings nicht als Utopie
85. sondern als konkretes Ziel verstanden werden.)
86.  
87.  
88. Ich lese all dies und schwebe auf Wolken ... dann aber, im
89. folgenden Absatz, stuerze ich ab. Er beginnt mit:
90.  
91. .QS
92. Program 1-1 contains a claring error.
93. .QE
94.  
95. Ich schaue mir also das Programm 1-1 an:
96.  
97. .CS
98. #include <stdio.h>
99. main()
100. {
101.         (void) printf("Hello World\\n");
102.         return (0);
103. }
104. .CE
105.  
106. Nun ... hmm ... einen herausstechenden Fehler kann ich nicht
107. erkennen. Nun gut, der int-Returnwert von main() fehlt, aber
108. ich weiss, dass der nicht noetig ist, weil int der Default
109. ist. Dann der void-Cast des Returnwerts von printf() --
110. kein Fehler ... nach meiner Ansicht zwar nicht optimal (weil
111. zuviel Noise fuer zu wenig Information oder Mehrwert), aber
112. in manchen Programmierkulturen durchaus so ueblich. Ebenso
113. die geklammerte Null nach dem Return, was nicht noetig
114. ist ... und falls man eine Funktionsaufrufsillusion beim
115. `return' *Statement* erzeugen wollen wuerde, sollte man den
116. Space vor der Klammer weglassen. (Aber besser keine falschen
117. Illusionen erzeugen, denn `return' ist keine Funktion.)  --
118. Alles Kleinigkeiten, die von unterschiedlichen
119. C-Programmier-Communities unterschiedlich bewertet werden.
120. Jedenfalls nichts was zu diesem folgenden Satz im Buch
121. passen wuerde:
122.  
123. .QS
124. It is an error that many programmers still make, and one that
125. causes more trouble than any other problem.
126. .QE
127.  
128. Ich hatte absolut keine Ahnung was er meinte.
129.  
130. Wenn ich dieses Beispielprogramm aus meiner Sicht
131. perfektionieren sollte, dann saehe es so aus:
132.  
133. .CS
134. #include <stdio.h>
135.  
136. int
137. main()
138. {
139.         printf("Hello World\\n");
140.         return 0;
141. }
142. .CE
143.  
144. (Die Version im K&R laesst den Return-Type `int' und das
145. `return'-Statement weg.)
146.  
147. Wo also ist der herausragende Fehler, der so viele Probleme
148. verursachen wuerde?
149.  
150.  
151. Die Aufloesung kommt im folgenden Satz:
152.  
153. .QS
154. The program contains no comments.
155. .QE
156.  
157. Und dann wird die ``verbesserte'' Version praesentiert
158. -- und ich befinde mich im freien Fall:
159.  
160. .CS
161. /********************************************************
162.  * hello -- program to print out "Hello World",         *
163.  *      Not an especially earth-shattering program.     *
164.  *                                                      *
165.  * Author:  Steve Qaulline                              *
166.  *                                                      *
167.  * Purpose:  Demonstration of a simple program          *
168.  *                                                      *
169.  * Usage:                                               *
170.  *      Run the program and the message appears         *
171.  ********************************************************/
172. #include <stdio.h>
173. main()
174. {
175.         /* Tell the world hello */
176.         (void) printf("Hello World\\n");
177.         return (0);
178. }
179. .CE
180.  
181.  
182. Was fuer ein Desaster!
183.  
184. So viel Gutes auf den ersten Seiten. So viel Hoffnungsvolles.
185. Und dann so eine desastroese Aussage und so ein desastroeses
186. Beispiel!
187.  
188. Da wird mir wieder richtig bewusst, warum Kernighan und Co.
189. soviel bessere Buecher zu diesen Themen geschrieben haben:
190. Sie haben stets Beispiele aus der Praxis verwendet. Hier dagegen
191. wurde ganz klar konstruiert. Kein Programmierer, der klar
192. denken kann, wuerde ein Hello-World-Programm kommentieren.
193. Man kann vielleicht noch darueber diskutieren, ob man kurze
194. Programme ueberhaupt kommentieren sollte, aber ein
195. Hello-World-Programm zu kommentieren ist schlichtweg
196. daneben. Der einzige ueberhaupt sinnvolle Kommentar bei einem
197. Hello-World-Programm ist, dass es sich bei ihm um ein
198. Hello-World-Programm handelt. ... Genauso wie der einzige
199. sinnvolle Kommentar bei der Verwendung von Duff's Device der
200. Hinweis ist, dass es sich um Duff's Device handelt. (Nicht
201. dass man Duff's Device einsetzen sollte, es liefert mir
202. hier nur ein bequemes Beispiel. ... und dieser noetige
203. Nachsatz demonstriert schon, warum man seine Beispiele gut
204. waehlen sollte.) Jedes Beispiel sollte ein Leitbild fuer
205. Produktivcode sein ... denn Menschen immitieren was sie
206. sehen.
207.  
208.  
209. Leider ist Quallines Verstaendnis von Kommentaren und deren
210. Beziehung zur Lesbarkeit von Code falsch. In Folge dieses
211. falschen Verstaendnisses macht er schaedliche Aussagen und
212. demonstriert ein fuer Anfaenger schaedliches Beispiel.
213. Ich finde das irritierend, weil er mit seinen sonstigen
214. Aussagen durchaus zeigt, dass er verstanden hat, worauf es
215. ankommt:
216.  
217. .QS
218. Your program should read like an essay. It should be as clear
219. and easy to understand as possible. Good programming comes
220. from experience and practice. The style described in the
221. following pages is the result of many years of programming
222. experience. It can be used as a starting point for developing
223. your own style. These are not rules, only suggestions. The
224. only rule is: make your program as clear, concise and simple
225. as possible.
226. .QE
227.  
228. Die Grundeinsichten sind also vorhanden, bloss fehlt es hier
229. und da an dem was einen Meister ausmacht. Er macht Schritte,
230. aber manchmal sind sie zu kurz. Er macht Schritte, aber nicht
231. immer konsequent genug.
232.  
233. Wenn ich mir vorstelle, wie Kernighan dieses Buch Anfang der
234. 90er Jahre angeschaut haben muss, in dem Bewusstsein, dass er
235. (gemeinsam mit Plauger) diese Themen bereits 1974 adressiert
236. hatte, aber scheinbar nicht genug davon bei den Programmierern
237. angekommen ist. Man bedenke nur folgende Lesson in Kernigan
238. und Plaugers Buch in Verbindung mit obigem ``verbessertem''
239. Code!
240.  
241. .QS
242. Don't just echo the code with comments -- make every comment
243. count.
244. .QE
245.  
246. Da ist es doch kein Wunder, dass Kernighan (diesmal mit Pike
247. zusammen) 1999 ``The Practice of Programming''
248. schreiben musste. Im Kern ist es eine Neuauflage von ``The
249. Elements of Programming Style''. Daneben kann man es sicher
250. auch als (korrigierende) Reaktion auf halbgute Buecher wie
251. ``Practical C Programming'' verstehen.
252.  
253. Es ist sehr schade, dass ``The Practice of Programming'' nie
254. wirklich bekannt geworden ist. Stattdessen wurde diese Rolle
255. dann von dem ein paar Jahre spaeter geschriebenen (mehr dem
256. Zeitgeist entsprechenden) ``Clean Code'' uebernommen, welches
257. in meinen Augen inhaltlich deutlich schwaecher ist.
258.  
259.  
260.  
261. Aber nochmal zurueck zu Quallines Fokus auf Kommentare. Seine
262. Grundziele sind ja nicht falsch, bloss seine Bewertung der
263. Mittel, um das Ziel zu erreichen, sind es. Ich war auch einmal
264. an diesem Punkt. Das relevante Aha-Erlebnis habe ich einem
265. Zusatzkurs im Studium zu verdanken. Es war ein Kurs zur
266. Aspektorientierten Programmierung in Java. Auch damals
267. schon hatte ich mit Java wenig am Hut, konzeptionell war
268. diese aspektorientierte Idee aber sehr interessant. Zudem war
269. der externe Dozent gut ... also inhatlich gut. (Es war ein
270. Wahlfach und ich nahm daraus eine meiner schlechten Noten im
271. Studium mit. Warum, weiss ich eigentlich bis heute noch nicht.
272. Es gab keine schriftlichen Pruefungen. Die praktischen
273. Uebungen haben mich wenig interessiert, weil ich nicht
274. Java-Programmieren sondern Konzepte lernen wollte, somit bin
275. ich da regelmaessig frueh gegangen. In den Vorlesungen habe
276. ich aber aktiv mitgemacht und mich oft gemeldet -- darauf
277. wollte er seine Note aufbauen -- scheinbar hat er da etwas
278. nicht recht auf die Reihe gebracht. Auf seine Frage, welche
279. muendliche Note ich mir denn selbst geben wuerde, habe ich,
280. fuer mich typisch, defensiv angesetzt. Er hat mich dann noch
281. tiefer verortet. Mit meinem heutigen Wissen muss ich zu dem
282. Ergebnis kommen, dass die Note voll daneben war. Ich hab
283. damals mein Gefuehl, dass die Note zu schlecht sei, einfach
284. ertragen, habe noch nicht einmal seine Entscheidung in Frage
285. gestellt. -- Tja, so passiert es einem, wenn man eher der
286. stillere, unsichere, introvertierte Typ ist.) Inhaltich war
287. der Kurs aber einer der Highlights meines FH-Studiums. Insofern
288. war er die schlechte Note vollkommen wert!
289.  
290. An einem Termin hat er den Kurs gefragt, welche
291. Moeglichkeiten es gaebe, den Sinn von Code zu transportieren.
292. Er wollte die wichtigsten Moeglichkeiten zuerst
293. hoeren. Ich habe mich als erster gemeldet (soviel zur Mitarbeit
294. ;-) ) und ``Kommentare'' vorgeschlagen ... ganz nach
295. Qualline-Art. Seine Reaktion darauf war die vermutlich
296. wichtigste Lektion zu Style beim Programmieren, die ich vom
297. Studium mitbekommen habe. Wirklich verstanden habe ich sie erst
298. in den Jahren danach. Dass ich aber immer wieder darueber
299. nachgedacht habe, lag daran, dass ich mir damals sicher war,
300. richtig zu liegen, aber dennoch eines Besseren belehrt wurde.
301. Er meinte, dass es etwas Wertvolleres im Code gaebe als
302. Kommentare und dass das die Bezeichner waeren. -- Wie Recht er
303. hatte!
304.  
305. Viele Jahre spaeter habe ich dann selber darueber geschrieben.
306. .[[ http://marmaro.de/apov/txt/2016-01-21_gute-bezeichner.txt
307.  
308.  
309. ``Practical C Programming'' ist eine wunderbare
310. Diskussionsgrundlage fuer ein Seminar ueber Programmierstil.
311. Man sollte das Buch aber fernhalten von Personen, die
312. moeglicherweise unreflektiert glauben was sie lesen.
313.  
314.  

Quellcode

Hier kannst du den Code kopieren und ihn in deinen bevorzugten Editor einfügen. PASTEBIN_DOWNLOAD_SNIPPET_EXPLAIN