Design <> Geschmack von Code
-
Im häufigsten Fall meinte der Ersteller wohl einfach "bekommen" - hat's aber falsch geschrieben (get programmieren und become kommentieren).
Ihr müßt mal Codes nach solchen Sachen durchsuchen, ist ein sehr beliebter Fehler in Kommentaren. Aber stellt Euch nun mal den armen Engländer vor, der diesen Kommentar liest. Er weiß ja nix von "bekommen" und darf nun rätseln, was eigentlich gemeint war.
-
Hallo.
Bei mir wird immer alles Englisch bezeichnet. Warum, weiß ich nicht, da eh niemand jemals meine Codes lesen wird. Aber es trainiert und hilft mir irgendwann vielleicht mal in der Schule
Bye.
-
Kommentare sollte man eh spärlich einsetzen... (aber zugegeben, meine Einbuchstabenbezeichner muss ich mir abgewöhnen :>)
-
Mr. N schrieb:
Kommentare sollte man eh spärlich einsetzen...
???
-
Mr. N schrieb:
Kommentare sollte man eh spärlich einsetzen... (aber zugegeben, meine Einbuchstabenbezeichner muss ich mir abgewöhnen :>)
Find ich auch. Besser verständlichen Code schreiben, der keiner Erklärung bedarf, als unverständlichen, der dann noch ne Seite Kommentar benötigt ...
Ich verwende nie Kommentare, hat sich bisher noch niemand beschwert.
-
dEUs schrieb:
Besser verständlichen Code schreiben, der keiner Erklärung bedarf, als unverständlichen, der dann noch ne Seite Kommentar benötigt ...
Fullack. Von Code, der vielleicht pro Funktion noch ne kurze Beschreibung braucht hat man viel mehr Lesbarkeit als von schlechtem Code wo dafür jede Zeile nen Kommentar enthält. Ausgenommen vielleicht größere Datenstrukturen, da schadet sowas manchmal nicht.
-
Im Kleinklein gebe ich Euch ja recht, aber es tut manchmal schon gut zu wissen, warum jemand zum Beispiel eine bestimmte Reihenfolge gewählt hat. Wenn also irgendwo ein if (Kontostand < Disporahmen) im Quelltext steht weiß ich natürlich auch ohne Kommentar sofort was passiert. Es ist aber später durchaus gut auch mal zu erfahren, warum die Prüfung zum Beispiel an dieser Stelle (nämlich bei der Abhebung) passiert und nicht bei den täglich Mahnläufen. Nur als Beispiel. Weil diese Infos ergeben sich auch aus klar lesbarem Code eindeutig NICHT.
Ein Kommentar soll also nicht das "Was" des Codes erklären, soweit soll der Code selbsterklärend sein. Aber zum "Warum" (auch: warum hat man ein bestimmtes Teil als 3 Klassen realisiert, in einem anderen Fall aber nur in einer einzigen) sagt lesbarer Code noch nicht allzu viel aus. Oder "warum" verbietet Ihr in einer Klasse die Ableitung? Gibt's da einen Grund? Oder "warum" dürfen diese Objekte nicht kopiert werden. Das ist manchmal schon interessant zu erfahren, wenn man fremden Code verstehen will.
-
Das stimmt allerdings auch ...
-
Wenn man zur Codeverständlichkeit komentieren muss ist es häufig an der Zeit übers Refaktorisieren nachzudenken.
(Falls das jetzt jemand falsch auffaseen sollte: Das geht in keiner Weise gegen Marc++us letze Antwort, sondern ist ein neues Thema)
-
Marc++us schrieb:
Wenn also irgendwo ein if (Kontostand < Disporahmen) im Quelltext steht weiß ich natürlich auch ohne Kommentar sofort was passiert.
Und ich weiß, was passieren wird. Konstostand und Disporahmen sind double und das Programm läßt nicht mehr zu, die Rundungsfehler zu verbuchen. Außerdem gehen dir Hälfte der Programmierer davon aus, daß sie nen Rahmen von 4000 haben, wenn sie ihr Konto um 4000 Überziehen dürfen. Die andere Hälfte geht von -4000 aus.