Ich finde es sollten zumindest so viele Kommentare im Quelltext sein dass man
das Programm in 5Jahren selbst wieder lesen kann und versteht.. Und das ist
manchmal gar nicht so einfach ;-)
Was allgemein auch hilft, ist einem Coding Standard zu folgen. Da scheiden sich
auch die Geister welchen man nimmt, aber dass man einen nimmt ist zumindest für
C++ dann unstrittig..
Und als Nächstes wäre noch wichtig Code-teile logisch sinnvoll zu trennen.
Beispiel Apfelmännchen: grafische Ausgabe vom berechnungscode zu trennen, und
dann die komplexen Zahlen einzeln dafür implementieren. Dann kannst Du alles
gedanklich getrennt behandeln, musst bei nachdenken über komplexe zahlen nicht
die byte-order für die Farben im bildschirmmodus wissen u.s.w.
Das sind nur so ein paar Dinge die gerne falsch gemacht werden..
---- Thomas Milius schrieb ----
In message <2095279992.754345.1455474752305.JavaMail.open-xchange@patina.store>
Steffen Huber <steffen@xxxxxxxxxxxx> wrote:
Tatsächlich gibt es seit einiger Zeit eine Programmier-Philosophie, die
behauptet, dass wenn Kommentare im Code stehen, es ein Zeichen dafür ist,
dass der Code selbst nicht aussagekräftig genug ist und einem Refactoring
unterzogen werden sollte. "Clean Code" ist der wahrscheinlich bedeutendste
Vertreter dieser Philosophie.
Wie hieß es doch früher zynisch, wenn der Entwickler zu faul war irgendwelche
Kommentare im Code zu hinterlassen: "Gute Programme sind selbsterklärend"
Genauso gut kann man sagen, daß Code der keine Kommentare enthält, einem
Refactoring unterzogen werden sollte.
Ich muß aber sagen, daß ich in den über dreißig Jahren, die ich jetzt
Programme unterschiedlichsten Kalibers in den unterschiedlichsten Sprachen
und an unterschiedlichsten Rechnern entwickelt habe, fast jede Meinung und
auch das Gegenteil dazu gehört habe. Da stumpft man ab. Ich habe genug von
diesen "Glaubenskriegen". Viele dieser Meinungen sind eh nur Aquise-Argumente
oder dazu da, den Code eines Kollegen in den Dreck zu ziehen, da man das
Programm des Kollegen eigentlich schon immer lieber selber geschrieben hätte.
Gelingt einem das, heißt es dann nach einiger Zeit, wenn das eigene Machwerk
nicht fertig wird:
1. Ich dachte nicht, daß XYZ so einen Mist programmiert hat. (Sprich,
ich hab die einfachsten Teile nicht verstanden)
2. Das ist alles viel komplizierter als gedacht, da hat XYZ vieles nicht
berücksichtigt (der erste Teil des Satzes stimmt, der zweite nicht)
3. Erst beim Update einer unterliegenden Bibliothek kann mein Genie
zum Tragen kommen und das Programm funktionieren (Dieses Update wird
frühestens in einem Jahrzehnt erwartet)
4. Die anderen Kollegen, auf deren Tabellen/Packages/Bibliotheken ich
zugreifen muß, sind alles solche Pfuscher wie XYZ. so kann mein Programm
nicht laufen (Mag sein, aber das würde es auch sonst nicht)
5. Sch...sse!!! Wie hat XYZ das nur gemacht?! Ich kriege es einfach nicht
auf die Reihe! (Das aber nur, wenn man meint, daß keiner zuhört.
Selbsterkenntnis führt nicht zwangsläufig zur Besserung. Es ist an
der Zeit das völlig mißratene Werk an jemand anders abzutreten und sich
daran zu machen über den nächsten Code herzufallen.)
6. Die lächerlichen Restarbeiten kann gut ABC machen (Beginne bei Punkt 1.)
Ich kann dem nur partiell folgen - zum einen sollten APIs m.E. immer
dokumentiert werden, und es gibt nicht selten die Notwendigkeit, zu
dokumentieren, warum die Lösung nun so aussieht, was die Alternativen
waren und warum man die Alternativen verworfen hat. Denn auch der cleanste
Code kann mir nichts über nicht im Code zu sehende Alternativen erzählen.
Volle Zustimmung und auch sonst können gute Kommentare die Analyse in die
richtige Richtung lenken. Programme, die man einfach so runter liest, haben
i.d.R. "Hello World"-Niveau. Komplexe und auch trickreiche Programme sind
keine Schande ganz im Gegenteil, man sollte sie aber warten können und dazu
sind gute Kommentare (d.h. nicht "i um einen erhöhen") hilfreich.
Thomas Milius
