neuer Lehrer, neues Schuljahr, neues "C++"
-
asc schrieb:
@It0101: Natürlich kommt eigene Erfahrung dazu (und auch das was man von anderen mitbekommt). Nur habe ich mich wenigstens (wenn auch durch einen anderen Grund) grundlegend mit Lernmethodiken und Psychologie in Zusammenhang mit Textgestaltung etc. beschäftigt - aber nein, Experte bin ich dadurch nicht. Mitleid hat aber noch nicht mal die Bereitschaft eine (In Buchstaben E I N E) google-Suche anzuschauen. Und er kann sogar gewisse Grundproblematiken in programmierfremden Themen finden (z.B. Bücher aus dem Bereich der Textsatz und -gestaltung).
Du hast dich damit beschäftigt und daraus deine Rückschlüsse auf den Kommentar-umfang in C++-Code gezogen. Das muss nicht zwangsläufig bedeuten, dass du recht hast. Aus meiner Sicht ist das immernoch eine subjektive Herangehensweise. Jeder Mensch ist anders, jeder programmiert anders und jeder versteht Code unterschiedlich schnell. Der eine findet zusätzliche Kommentare wichtig, der andere kommt auch ohne klar.
Ich z.B. vermeide unnötiges Vollspammen des Sourcecodes mit Kommentaren ( ein Kommentar für den Funktionsheader und gut is ) und ich vermeide todbringende, verständnis-erschwerende, aus gefühlten 7 verschiedenen STL-Komponenten bestehende Einzeiler.
Ich steh also mit meiner subjektiven ( aber für mich angenehmen ) Meinung irgendwo zwischen euch.
Die Diskussion ist sinnlos, weil die Herangehensweise subjektiv ist und es keine exakte Lösung gibt.
-
@hustbaer
Zitat aus "The Elements of C++ Style": 34. Keep Your Comments and Code Synchronized ... When you modify code, make sure you also update any related comments. The code and documentation together form a software product, so treat each wich equal importance.Wenn es unübersichtlich wird, dann nicht wegen den Kommentaren. Genauso könntest du das Einrücken im Quelltext vernachlässigen und dich anschließend beschweren.
@asc + Shade of Mine
Ich habe in meinem ersten Beitrag mit Absicht die Worte "MEINER ANSICHT NACH" eingebaut.Ihr versucht doch hier durch Beiträge wie
Shade Of Mine schrieb:
Ne, doku lesen.
Man kommentiert keine standard funktionen, das ist ja wahnsinn...
den Eindruck zu erwecken, dass eure Aussage allgemein gültig wäre, also seid ihr in der Beweispflicht und nicht ich. Deshalb googele ich auch nicht rum, um eure Thesen zu beweisen/ zu widerlegen bzw. ich weiß, nachdem ich gestern 3 Bücher (unter anderem Code Complete, wo das Thema detailiert behandelt wird) überflogen habe, dass die google-Treffer auch nichts Neues bringen werden, weil es diese Regel allgemein schlicht nicht gibt. Wäre ja auch Unsinn.
Ansonsten siehe Beitrag von It0101.
P.S.:
@Shade of Mine
Habe die Buchempfehlungen überflogen und nichts dergleichen gefunden. Im Prinzip steht überall mehr oder weniger dasselbe, Teils mit Widersprüchen in Detailfragen. Einschränkungen bzgl. der Standarddinge gibt es nicht. Vielleicht noch am ehesten in Simons Buchempfehlung.Ich habe aber auch nicht behauptet ich würde sprechende Funktionen wie copy, sort, usw. nochmal kommentieren sondern Dinge die nicht unbedingt intuitiv sind. Und dieses Interator-Objekt ist es für mich nicht, also kommt ein kurzer Kommentar hin, ohne Rücksicht auf Pseudoregeln und ungeschriebene Gesetzte. Denn die Chancen stehen gut, dass ICH derjenige bin der dann später die Stelle wieder begreifen muss.
-
Mitleid schrieb:
34. Keep Your Comments and Code Synchronized ... When you modify code, make sure you also update any related comments.
Eine schöne Regel, die aber schnell mal vergessen geht - und dann sind Kommentare gefährlich.
Mitleid schrieb:
Wenn es unübersichtlich wird, dann nicht wegen den Kommentaren.
Du meinst also, Kommentare tragen immer nur positiv zur Übersichtlichkeit bei?
Klar kann es bei verschachtelten STL-Massenkonstrukten mit vier verschiedenen Algorithmen von Vorteil sein, wenn mal ein Kommentar da steht. War vielleicht etwas zu extrem ausgedrückt von den Verfechtern. Aber grundsätzlich - im Allgemeinen hat man nämlich recht einfache Funktionsaufrufe und Deklarationen - finde die Regel, Dinge aus der Standardbibliothek nicht zu kommentieren, nicht sehr abwegig...
-
Mitleid schrieb:
also seid ihr in der Beweispflicht und nicht ich.
Ich muss niemanden etwas beweisen. Es ist ein reiner Akt der freundlichkeit wenn ich dich auf deine Fehler hinweise, mehr nicht.
Habe die Buchempfehlungen überflogen und nichts dergleichen gefunden. Im Prinzip steht überall mehr oder weniger dasselbe, Teils mit Widersprüchen in Detailfragen. Einschränkungen bzgl. der Standarddinge gibt es nicht. Vielleicht noch am ehesten in Simons Buchempfehlung.
Natürlich schreibt niemand "Dokumentiere nie eine Standard Funktion". Weil das wäre ja dumm soetwas zu schreiben. Es geht darum den Verstand zu gebrauchen: nämlich was alle diese Bücher dir sagen werden ist: Dokumentiere das Warum, nicht das Wie.
Und genau das impliziert eben dass es unnötig ist einen istream_iterator<T>() explizit zu kennzeichnen, da ein Druck auf F1 genau das tut. Du musst nicht verstehen wie es technisch genau abläuft um den Code zu verstehen - du musst nur verstehen was hier passiert und das ist ohne details zu wissen trivial möglich. Viel wichtiger dagegen ist es zu wissen WARUM hier der Code steht. Wieso stdin? Wieso accumuluate? Wieso bis EOF?
Lies die Bücher die ich genannt habe nochmal, denn genau das steht dort drinnen. Kommentare erklären das Warum.
Und dann einfach weiter denken.
Ich habe aber auch nicht behauptet ich würde sprechende Funktionen wie copy, sort, usw. nochmal kommentieren sondern Dinge die nicht unbedingt intuitiv sind. Und dieses Interator-Objekt ist es für mich nicht, also kommt ein kurzer Kommentar hin, ohne Rücksicht auf Pseudoregeln und ungeschriebene Gesetzte. Denn die Chancen stehen gut, dass ICH derjenige bin der dann später die Stelle wieder begreifen muss.
Klar, mach das. Hindert dich niemand daran. Nur tu das nicht an die große Glocke hängen dass dir dann jemand vielleicht noch glaubt dass das gut so ist.
Natürlich tut ein kleiner Kommentar hier nicht weh, aber man muss irgendwo die Grenze ziehen. Zuviele Kommentare erschweren die Wartbarkeit des Codes. Man muss mehr lesen und man muss mehr updaten. Auch laufen solche Kommentare sehr viel schneller out-of-sync mit dem echten Code. Das sind ein paar der vielen Probleme von zu exzessiven Kommentieren. Wenn man aber einfach das WARUM dokumentiert, fallen plötzlich fast alle Probleme weg.
das accumulate verwendet übrigens ein standard c++ idiom. siehe dazu auch advanced c++ programming - furchtbar interessant das buch.
Gerade hier wo es ja ums lernen geht, ist es wichtig sauberen Code zu lernen. Gute Kommentare sind enorm selten und deshalb sollte man hier anfangen, hier wo die Ausbildung ja quasi stattfindet. Wo wenn nicht hier den Leuten die sachen richtig beibrigen?
Und BTW Kommentare am Zeilenende sind früher oder später durcheinander. Das ist ein No-Go. Denn die Zeilen werden irgendwann einmal die Länge verändern und du darfst nicht einfach die Kommentare in anderen Zeilen mitändern, damit beschmutzt du sinnloserweise den VCS-changelog. Selbiges bei einem update der Kommentare. Ne ne, solange VCS Systeme Zeilen basiert sind nur eine Sache pro Zeile.
-
Shade Of Mine schrieb:
Ich muss niemanden etwas beweisen. Es ist ein reiner Akt der freundlichkeit wenn ich dich auf deine Fehler hinweise, mehr nicht.
Du meinst wohl wo ich DEINER Meinung nach einen Fehler begehe. Nur bist du halt keine Kapazität und die Kapazitäten auf dem Gebiet bestätigen dein Gequassel nicht, sonst könnte man es auch an entsprechender Stelle nachlesen.
Wenn man es für nötig hält auch mal Standarddinge zum besseren/schnelleren Verständnis zu kommentieren, kommentiert man noch lange nicht exzessiv. Man muss ja nicht übertreiben.
Shade Of Mine schrieb:
Natürlich tut ein kleiner Kommentar hier nicht weh, aber man muss irgendwo die Grenze ziehen.
Man muss ein Maß finden, das ist richtig, aber so exakte Grenzen wie "kommentier keine Standardfunktionen" werden nicht gezogen, weil das Unsinn ist.
Shade Of Mine schrieb:
Lies die Bücher die ich genannt habe nochmal, denn genau das steht dort drinnen. Kommentare erklären das Warum.
Das finde ich richtig niedlich. Zwei davon hatte ich bereits in der Hand, da warst du noch nicht mal flüssig. Ich kann sie auch tausendmal überfliegen, deine Aussage bleibt trotzdem falsch.
nicht intuitive Dinge bzw. nicht für sich sprechende Dinge aus dem Standard zu kommentieren != exzessiv kommentieren
Es heißt man braucht Frauen nur lange reden zu lassen, dann widersprechen sie sich selbst. Offensichtlich gilt das auch für angehende Programmierer
Shade Of Mine schrieb:
Man kommentiert keine standard funktionen, das ist ja wahnsinn...
...etwas später...
Shade Of Mine schrieb:
Natürlich schreibt niemand "Dokumentiere nie eine Standard Funktion". Weil das wäre ja dumm soetwas zu schreiben.
In diesem Sinne nochmal der Hinweis auf It0101s Beitrag.
Nexus schrieb:
Eine schöne Regel, die aber schnell mal vergessen geht - und dann sind Kommentare gefährlich.
Pfusch ist immer ungünstig.
Nexus schrieb:
Du meinst also, Kommentare tragen immer nur positiv zur Übersichtlichkeit bei?
Nein, ich meine man kann Kommentare so platzieren, dass sie den Lesefluss nicht stören. Wenn dann Änderungen am Quelltext vorgenommen werden und die Ordnung rücksichtslos durcheinandergebracht wird liegt die mangelnde Übersicht nicht an den Kommentaren sondern am Pfusch.
Nexus schrieb:
finde die Regel, Dinge aus der Standardbibliothek nicht zu kommentieren, nicht sehr abwegig...
Wenn einzelne das für sich oder ihre Firma so ableiten um damit die zügellosen "Kommentatoren" einzufangen, dann ist das ihr gutes Recht. Wichtig ist es das Maß zu finden. Inwieweit einem so eine strikte Regel helfen kann, soll dann jeder für sich entscheiden. Ich halte sie nicht für sinnvoll und sie ist mir auch in der Praxis noch nicht begegnet.
.
-
Mitleid schrieb:
Nexus schrieb:
Eine schöne Regel, die aber schnell mal vergessen geht - und dann sind Kommentare gefährlich.
Pfusch ist immer ungünstig.
Ja, aber auf Sprachebene haben wir doch auch Möglichkeiten, Pfusch einzuschränken. Ich meine ja nicht, dass die Regel nicht gut wäre oder sie durch Pfusch sinnlos würde - sondern, dass jeder zusätzliche Kommentar diesbezüglich gewisse (wenn auch geringe) Risiken birgt und es selbst ungeachtet der Übersichtlichkeit nicht nur Vorteile hat, viel zu kommentieren.
Speziell bei solchen STL-Ausdrücken braucht man ja nur einen kleinen Teil (z.B. einen übergebenen Funktor) leicht abzuändern, um die Bedeutung komplett zu verändern.
Mitleid schrieb:
Nein, ich meine man kann Kommentare so platzieren, dass sie den Lesefluss nicht stören. Wenn dann Änderungen am Quelltext vorgenommen werden und die Ordnung rücksichtslos durcheinandergebracht wird liegt die mangelnde Übersicht nicht an den Kommentaren sondern am Pfusch.
Da stimme ich dir fast zu, aber bezüglich Lesefluss kann es bei vielen Kommentaren schwierig werden. Oder der Fluss bleibt zwar erhalten, aber die Informationsrate (relevante Informationsgewinne durch Kommentare pro Sekunde) sinkt.
Ansonsten bin ich gleicher Meinung. Was zu viel ist und wann ein Kommentar als überflüssig erachtet wird, hängt definitiv vom Betrachter ab - auch wenn die meisten Leute im Grossen und Ganzen wohl ähnlicher Ansicht sind.
-
Mitleid schrieb:
@hustbaer
Zitat aus "The Elements of C++ Style": 34. Keep Your Comments and Code Synchronized ... When you modify code, make sure you also update any related comments. The code and documentation together form a software product, so treat each wich equal importance.Wenn es unübersichtlich wird, dann nicht wegen den Kommentaren. Genauso könntest du das Einrücken im Quelltext vernachlässigen und dich anschließend beschweren.
Ich sehe diese Stellen nichtmal.
Schonmal was von "Refactor-Rename" gehört?
-
Shade Of Mine schrieb:
Es geht darum den Verstand zu gebrauchen: nämlich was alle diese Bücher dir sagen werden ist: Dokumentiere das Warum, nicht das Wie.
Also ich denke, das kann ich so unterschreiben.
Dennoch halte ich es für kontraproduktiv die von mir erwähnten überdimensionierten Massiv-STL-Einzeiler zu konstruieren. Wer unbedingt cool sein will, soll sich sein Basecap schräg aufsetzen...
-
It0101 schrieb:
Wer unbedingt cool sein will, soll sich sein Basecap schräg aufsetzen...
Man ist schon cool, wenn man das Wort "Basecap" (Basiskappe?) benutzt.
-
volkard schrieb:
It0101 schrieb:
Wer unbedingt cool sein will, soll sich sein Basecap schräg aufsetzen...
"Basecap" (Basiskappe?)
Von der Basecap werden alle anderen Kappen abgeleitet. Sowas sollte in der Doku stehen!
-
all your basecap
-
hustbaer schrieb:
all your basecap
belong to us
-
ich wusste, dass ich das nicht hätte schreiben sollen... Ihr Kinder!!!
-
volkard schrieb:
hustbaer schrieb:
all your basecap
belong to us
Du hast das "are" vergessen. :p
-
volkard schrieb:
hustbaer schrieb:
all your basecap
belong to us
-
drakon schrieb:
volkard schrieb:
hustbaer schrieb:
all your basecap
belong to us
-
erna schrieb:
drakon schrieb:
volkard schrieb:
hustbaer schrieb:
all your basecap
belong to us
