3. neuer Lehrer, neues Schuljahr, neues "C++"

neuer Lehrer, neues Schuljahr, neues "C++"

  • ?

    Shade Of Mine schrieb:

    Zum zügig verstehen sind kommentare sogar hinderlich 😉

    Zwecklose philosophische Diskussion. Ich könnte mit gleichem Recht das Gegenteil behaupten.

    Selbst die ungeliebten Einzeiler müssen (richtig platziert) nicht stören:

    Quelltext Quelltext                        // Kommentar
    Quelltext Quelltext                    // Kommentar
	Quelltext Quelltext                    
	    Quelltext Quelltext                // Kommentar
	Quelltext Quelltext                    
Quelltext Quelltext

    Musst sie ja nicht beachten, wenn du lieber F1 drückst. 😉

    Shade Of Mine schrieb:

    Mich interessiert in kommentaren aber keine doku ala
    ++i; //i wird um eins erhöht

    Ich habe im letzten Beitrag dazu nichts gesagt, weil das trivial ist. Das interessiert keinen und es kommt auch in (fast) jeder Empfehlung/Vorgabe als Beispiel wie man es nicht machen sollte.

    Eine kurze Bemerkung zu diesem Iteratorobjekt finde ich trotzdem nicht verfehlt. Manche würden sogar grundsätzlich jeder Deklaration einen Kommentar hinzufügen. Also vielleicht so:

    // ...
int n=0;                              // Zählvariable
std::istream_iterator<int> eof;       // bla bla bla
// ...

    Aber, wir reden hier sowieso über persönliche Vorlieben, Styleguides usw., also recht individuelle Dinge. Deswegen wünschte ich mir (wenn so Aussagen kommen, wie "das ist ja Wahnsinn" usw.) die Protagonisten könnten noch etwas mehr vortragen, als ihre Meinung. Solche Aussagen erwecken nämlich den Eindruck einer Allgemeingültigkeit, die ja wohl hier nicht gegeben ist.

    0
  • A

    Mitleid schrieb:

    Shade Of Mine schrieb:

    Zum zügig verstehen sind kommentare sogar hinderlich 😉

    Zwecklose philosophische Diskussion. Ich könnte mit gleichem Recht das Gegenteil behaupten.

    Such doch einfach mal in google nach "zu viele kommentare" (es kommen sogar Buchtreffer, Informatikskripte usw.)...

    Zusätzlich kann man dann noch auf gewisse Grundprinzipien der Psychologie zurückgreifen, wenn dir das noch nicht reicht.

    0
  • A

    Mitleid schrieb:

    Selbst die ungeliebten Einzeiler müssen (richtig platziert) nicht stören:

    Sie stören schon dadurch das sie in der Regel durch eine andere Farbe hervorgehoben werden (das ist das gleiche Prinzip als wenn du etwas fett schreibst - das Auge wandert dahin). Und wenn du in einem Text zuviel hervorhebst nützt es ebenso niemanden.

    0
  • S

    Mitleid schrieb:

    Solche Aussagen erwecken nämlich den Eindruck einer Allgemeingültigkeit, die ja wohl hier nicht gegeben ist.

    Lies einfach gängige Literatur zu dem Thema 😉

    0
  • ?

    @asc
    Ich brauch nicht nach irgendwelchen Tutorials zu googeln. Diverse, auch sehr bekannte, Werke liegen direkt vor mir und ich habe mir gestern Abend sogar die Mühe gemacht die entsprechenden Kapitel nochmal zu überfliegen. Vielleicht bin ich ja zu blöd um die Stellen zu finden, aber in keinem Buch, Guideline, usw. an das ich mich erinnere kommt eine Vorgabe, dass Standarddinge nicht kommentiert werden sollen/dürfen/müssen. Über Kommentare zu Offensichtlichem waren wir uns ja einig.

    Für die Kommentare kannst du dir ja auch ein seichtes Grau einstellen, wenn es dich stört.

    Meine Augen sind inzwischen schon so geschuhlt, dass sie beim // sofort ein CR durchführen, falls ich dem Quelltext noch folgen kann. 😃 Wenn nicht, wird der Kommentar gelesen.

    @Shade Of Mine
    Zitier mir Stelle wo du das gelesen hast. Ich kann das sofort nachlesen, denn wenn das Buch gängig ist, liegt es hier bei uns sicher rum. Auf die dort aufgeführte Begründung bin ich sehr gespannt.

    Ich befürchte aber du schießt mit Platzpatronen. 😉

    0

  • Das schlimmste an dieser Diskussion ist hier eigentlich, dass jeder versucht, seine eigene subjektive Meinung und seine Erfahrungen als "die Wahrheit und nichts als die Wahrheit" zu verkaufen...

    Ich hab dazu auch eine Meinung, aber ich behaupte nicht, dass alle anderen Meinungen falsch sind. Es sind halt einfach Meinungen.
    Jeder kommentiert wie er das für richtig hält, deswegen müssen andere Lösungsansätze nicht unbedingt falsch sein.

    Einige der anerkannten C++-Helden hier im Forum sind in der Hinsicht teilweise etwas verbohrt...

    0
  • S

    Mitleid schrieb:

    @Shade Of Mine
    Zitier mir Stelle wo du das gelesen hast. Ich kann das sofort nachlesen, denn wenn das Buch gängig ist, liegt es hier bei uns sicher rum. Auf die dort aufgeführte Begründung bin ich sehr gespannt.

    Zitier du mir doch einfach Stellen aus bekannten Büchern wo gesagt wird dass standard funktionen kommentiert werden sollen. 😉

    Das Problem ist, dass ich jetzt sicher keine mehreren tausend Seiten durchsuchen werde. Nehmen wir als Beispiel Elements of Programming Style. Da gibts mindestens einen Abschnitt wo es um "good comments clarify intent" geht. In TCPL und K&R steht sicher auch etwas ähnliches, zumindest in Programming Principles and Practice Using C++ schreibt Stroustrup darüber. Code Complete hat glaub ich sogar ein Kapitel zu diesem Thema.

    Kommentare sind jetzt nicht so das Thema wo man viel mehr als ein
    Comments explains why
    Code explains how
    sagen kann. Google mal danach. zB bei thedailywtf oder codinghorror gibt es immer wieder einträge dazu.

    0
  • S

    It0101 schrieb:

    Das schlimmste an dieser Diskussion ist hier eigentlich, dass jeder versucht, seine eigene subjektive Meinung und seine Erfahrungen als "die Wahrheit und nichts als die Wahrheit" zu verkaufen...

    Jau! 👍
    Ist mir schon bei einigen Foren aufgefallen:



    Jeder nur ein Kreuz

    @Topic:
    Mir persönlich gefällt "Stephen C. Dewhurst: C++ Gotchas; Kap1: Excessive commenting". 😃

    Gruß,

    Simon2.

    0
  • A

    Mitleid schrieb:

    @asc
    Ich brauch nicht nach irgendwelchen Tutorials zu googeln.

    Ich habe nicht von Tutorials gesprochen - dank google books wirst du auch Bücher finden. Zudem verlangst du nach Beweisen, dann erwarte ich auch das du in der Lage bist zumindest einmal eine google-Suche zu starten und zumindest die ersten 2-3 Seiten der Ereignisse zu überfliegen.

    @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).

    0

  • Mitleid schrieb:

    Selbst die ungeliebten Einzeiler müssen (richtig platziert) nicht stören:

    Quelltext Quelltext                        // Kommentar
    Quelltext Quelltext                    // Kommentar
	Quelltext Quelltext                    
	    Quelltext Quelltext                // Kommentar
	Quelltext Quelltext                    
Quelltext Quelltext

    Nach ein paar Monaten und einer halben Flasche Refaktorieren sieht das dann so aus:

    Quellteeeeeeeeext Quelltexttttttttttt                        // Kommentar
    Quelltext Quel                    // Kommentar
	Quelltext                    
	    Quelltext Quelltext                // Kommentar
	Quelltext Quelltexttt                    
Quelltext Quelltext

    wow.
    übersichtlich.

    0

  • 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.

    0
  • ?

    @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.

    0
  • N

    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...

    0
  • S

    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.

    0
  • ?

    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.

    .

    0
  • N

    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.

    0

  • 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?

    0

  • 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...

    0
  • V

    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.

    0
  • ?

    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!

    0
Anmelden zum Antworten