V
otze schrieb:
314159265358979 schrieb:
Kommentare sind übrigens üblicherweise ein Zeichen von schlechtem Code.
Das stimmt nicht.
Das stimmt aber auch nicht.
otze schrieb:
Kommentare sind üblicherweise ein zeichen für Code, der mehr macht als simple GUI-Boilerplate Logik. Wenn du einen Algorithmus implementierst, dann gibt es oftmals teile, die zwar im originalpaper hergeleitet wurden, aber die Herleitung hat keine Intuition die stark genug ist, dass sprechende Variablennamen alleine den Code beschreiben können.
Das wäre der Idealfall. Ich beneide Dich um die Arbeitskollegen, die das auch so handhaben.
In der Welt passiert aber leider sowas:
http://stackoverflow.com/questions/3198615/wrote-a-quick-and-dirty-brainfuck-interpreter-what-could-i-do-better
Auf den ersten Eindruck erscheint es wie ein bestens kommentiertes Programm; es kann sogar Profis beeindrucken, wie hübsch es doch sei. Und zu sowas führt es, wenn man Anfänger zwingt, viele Kommentare zu schreiben. In Wirklichkeit ist es schlechtestens kommentiert. Die ganzen einfachen Sachen sind kommentiert, sodaß man alles doppelt liest, aber der elegante Trick, wie '[' und ']' zusammenarbeiten, ist kein Bißchen kommentiert(*). Da stottert man beim Lesen. Und zwar nicht umsonst: Der Code ist falsch.
Ich halte es so, daß ich dermaßen ausgewalzte Kommentare ein Zeichen von Unverständnis und Praxisferne halte, ein fettes Warnblinklicht, das mir sagt, ich hätte mich da nicht einmischen sollen, dann hätte ich den Code jetzt auch nicht lesen müssen.
Vielleicht wäre es gut, die Anfänger nicht mehr zum Kommentieren anzuhalten. Und die Profis sollten vor jede Klasse schreiben (können), warum sie diese Klasse einführen. Das wäre schön. Ach, was würden viele RessourcenManager und curiously recurring templates sterben. Nee, das klappt nie:
class RessourcenManager{
//Diese Klasse managt Ressourcen, ist doch kla, du.
...//weiter wie gehabt, oder noch schlimmer
^(*) Man erkennt nur am ?:-Operator, daß der Schreiber sich dort viele Gedanken gemacht hat und ein Profi ist.^
