neuer Lehrer, neues Schuljahr, neues "C++"
-
Was intuitiv ist, hängt logischerweise davon ab, was man selbst verwendet, und was man kennt.
Jemand der std::istream_iterator nicht kennt, wird ein Konstrukt welches std::istream_iterator verwendet vermutlich nicht intuitiv finden (SO eindeutig ist der Name ja nicht). Jemand der es selbst schon öfter verwendet hat dagegen schon.Andrerseits halte ich es auch nicht für gut, alles zu kommentieren, was irgendjemand, der in der selben Firma bzw. am selbem Projekt arbeitet, nicht kennen könnte. Dann müsste man fast jede Zeile kommentieren.
Gerade Kenntnisse der Standard-Library sollte man finde ich voraussetzen können. Nicht in dem Sinn dass jeder schon die ganze SCL auswendig kennen muss, aber in dem Sinn, dass er/sie es sich gefälligst anzusehen hat, wenn er/sie es noch nicht kennt. Schadet ja nicht, sich "nebenbei" etwas weiterzubilden.
Nenn mir eine. Die schreibe ich heute noch an und frage nach einer "guten" Begründung.
Wir haben das so ähnlich in unseren Coding-Guidelines stehen.
Was offensichtlich ist, sollte nicht kommentiert werden. Grund: es erzeugt "noise", es bremst beim Lesem. Sprechende Variablen-, Funktions- und Klassennamen sind da wesentlich hilfreicher.
Wenn jemand zu viel (sinnlose) Kommentare schreibt, wird es aber maximal eine freundlich vorgetragene Bitte geben, dass er es in Zukunft anders machen soll. (Meist sind die Leute die viel Kommentare schreiben auch die, die schlechte Namen verwenden - von daher heisst es dann meistens "verwende bitte bessere Namen, dann musst du auch nicht so viel Kommentare schreiben").
Grund für Stunk oder auch nur ein "ernstes Gespräch" war sowas bei uns noch nie. Und es wird auch nicht systematisch überprüft.
-
Mitleid schrieb:
asc schrieb:
Dennoch ist eine solche Regel durchaus bei der ein oder anderen Firma üblich - und zwar aus guten Grund.
Nenn mir eine. Die schreibe ich heute noch an und frage nach einer "guten" Begründung.
Ich nenn dir keine (meinen Lebenslauf breite ich in der Öffentlichkeit nicht aus), kann dir aber versichern das diese Regel in jeder meiner bisherigen ein ungeschriebenes Gesetz war [und ich erinnere mich an eine Firma wo dies sogar in den Programmierrichtlinien stand - die einzige in der ich tatsächlich eine solche vorliegen hatte]. Und es scheint sogar in einigen Institutionen im Öffentlichen Dienst so zu gelten, zumindest kann ich dies aus Kommentaren meines Vaters ableiten - als ich noch ausschließlich privat entwickelt hatte.
Ich finde das Kommentieren von Algorithmen und Bestandteile zu den verwendeten Standardbibliotheken (unabhängig von der Sprache) grundsätzlich nur dann sinnvoll sind, wenn sie eine wirkliche Ausnahme darstellen (was hier nicht der Fall ist). Und wenn in einem Projekt die Standardbibliothek intensiv eingesetzt wird, muss sich eh jeder zumindest die Grundlagen beibringen.
Zudem sollten Funktionen eh möglichst kurz sein um den Code gut überschauen zu können.
Mitleid schrieb:
asc schrieb:
der inflationäre Einsatz wirkt aber Kontraproduktiv.
Ein kurzer Kommentar am Ende der Zeile ist nicht übertrieben.
Doch ist sie. Und da spreche ich nicht nur auch aus eigener Erfahrung. Wenn zu viele Kommentare im Code stehen (und dies wird bei dir der Fall sein wenn du bereits hier kommentierst) überliest man sie. Das Menschliche Gehirn nimmt Ausnahmen besser wahr, als den Regelfall.
Mitleid schrieb:
asc schrieb:
... und wer zumindest grundlegende Ahnung von den STL-Algorithmen hat, braucht in dem erwähnten Fall auch keine Hilfe ...
Na ja, Hilfe braucht sowieso keiner, wenn er genug Zeit hat.
Die Aussage ist schlicht und ergreifend Schwachsinn. Wer keine Hilfe braucht, hat vermutlich nur Angst sich die Blöße zu geben. Sieht man doch auch an Schülern, Auszubildenden oder Studenten => Es kommen keine Fragen, weil man nicht Zeigen will das man es nicht versteht - auf direktes Fragen hin wird man aber Kleinlaut.
Mitleid schrieb:
Falls einer das kennt und auch selbst häufig einsetzt braucht er keine Hilfe,...
Was man genau in Projekten von Firmen erwarten kann (oder noch extremer: muss). Es ist nicht verkehrt komplexe Abläufe zu beschreiben - aber bitte keine Fälle die im Kontext einfach sind. Ja, ein Schüler kann dies kommentieren, aber nein, in Firmencode stellt dies eher ein Armutszeugnis dar.
Und das sagt jemand wie ich, der wirklich viel kommentiert (aber in 99% der Fälle nur auf Ebene der Funktion und seiner Eingabe- und Ausgabegrößen; zudem eigentlich nur im Header).
-
hustbaer schrieb:
Wenn jemand zu viel (sinnlose) Kommentare schreibt, wird es aber maximal eine freundlich vorgetragene Bitte geben, dass er es in Zukunft anders machen soll.
Dies entspricht auch der Erfahrung wie es in meinen bisherigen Firmen der Fall war.
hustbaer schrieb:
(Meist sind die Leute die viel Kommentare schreiben auch die, die schlechte Namen verwenden...
...oder sie Kommentieren im Gegenzug gar nicht. So meine Erfahrung.
-
pumuckl schrieb:
Mal abgesehen von den diversen bereits genannten Probleme bzgl. Eingabefehlern etc. finde ich den Einzeiler nicht so unheimlich schlimm. Allerdings geben ich den Kritikern recht, die die Lesbarkeit nicht so umwerfend finden. Ein oder zwei wohlplazierte Zeilenumbrüche können da Wunder wirken:
#include <iostream> //std::cin / std::cout / std::endl #include <iterator> //std::istream_iterator #include <numeric> //std::accumulate int main() { std::cout << std::accumulate(std::istream_iterator<int>(std::cin), std::istream_iterator<int>(), 0) << std::endl; }Machts in meinen Augen genügendlesbar - ws natürlich auch wieder Geschmackssache ist...
Clean code reads like well-written prose. - Gary Booch
Als schöne Prosa würde ich es immer noch nicht bezeichnen.
-
@asc
Also, ich stimme dir und hustbear in dem Punkt zu, dass offensichtliche Dinge keines Kommentars bedürfen. Aber c++ und gerade die STL sind alles andere als selbstdokumentierend. Deshalb sehe ich gerade bei STL-Konstruktionen lieber mehr Kommentare als weniger.Wie gesagt, mir ist die Vorgabe Standardfunktionen oder Standardobjekte nicht nochmal kommentieren zu dürfen, weder in Lehrbüchern, noch in den Unternehmen begegnet. Kann mir auch nicht vorstellen, dass das Sinn macht.
Wenn du hier alles Mögliche anführst, dann lass doch den Behauptungen harte Fakten folgen (z.B. den Link auf ein Standarddokument, eine Richtlinie, ... was auch immer)
asc schrieb:
Die Aussage ist schlicht und ergreifend Schwachsinn.
Ein Quelltext ist bereits selbst eine exakte Beschreibung. Wer genug Zeit hat, kann sich auch ohne die Hilfe von Kommentaren klar machen, was mit dem Quelltext bezweckt wird. Was das mit Angst sich die Blöße zu geben zu tun hat ist mir nicht ganz klar.
P.S.: Wenn ich nochmal darüber nachdenke, brauchst du keine harten Fakten zu liefern, denn ich habe bereits jetzt das Gefühl zu viel Zeit mit der Diskussion über diese Lappalie verschwendet zu haben. Ich muss mir diese Bagatelldiskussionen mal abgewöhnen. Da könnten wir uns gleich über die bessere Lieblingsfarbe streiten. Ist genauso produktiv.
-
Aber es gibt doch genug Bücher und Webseiten zur Standardbibliothek. Da reicht doch "rtfm" als Kommentar.
-
Mitleid schrieb:
...Aber c++ und gerade die STL sind alles andere als selbstdokumentierend....
Ich vermute, dass das (auch) ganz banal daran liegt, dass die Ausdrücke englisch und/oder zum Teil weniger geläufig sind.
Ich persönlich finde den Aufruf einer Funktion, die heißt: "Summiere()" (bzw. "accumulate()") deutlich verständlicher als ein Schleife. Besonders, wo es für Schleifen x verschiedene Stile gibt....
Wenn ich diese Ausdrücke in (vernünftiges/passendes) Deutsch übersetze, gibt es jedenfalls nur sehr wenige Algorithmen, die ich nicht auf Anhieb oder falsch verstehe:
for_each find find_if find_end find_first_of adjacent_find count count_if mismatch equal search search_n copy copy_backward swap swap_ranges iter_swap transform replace replace_if replace_copy replace_copy_if fill fill_n generate generate_n remove remove_if remove_copy remove_copy_if unique unique_copy reverse reverse_copy rotate rotate_copy random_shuffle partition stable_partition sort stable_sort partial_sort partial_sort_copy nth_element lower_bound upper_bound equal_range binary_search merge inplace_merge includes set_union set_intersection set_difference set_symmetric_difference push_heap pop_heap make_heap sort_heap min max min_element max_element lexicographical_compare next_permutation prev_permutation... und ich gehe mal noch weiter: Ich habe schon haufenweise Code gesehen, bei denen die "handgeschriebenen" Schleifen dann in Funktionen ausgelagert wurden, die fast genauso hießen wie eine der oben genannten ...
Ich kann allerdings verstehen, dass das Iterator-Konzept (besonders in Verbindung mit Streams) (mir) nicht ganz so in Fleisch und Blut übergegangen ist. Und deswegen muss ich bei diversen STL-Einsätzen nochmal kurz nachsehen/-denken... die Algorithmen aber finde ich extrem sprechend (solange man sie nicht "mißbraucht").
Gruß,
Simon2.
-
- erledigt - Danke.
-
Mitleid schrieb:
accumulate ist nicht das Problem. Nebenbei geht es auch nicht um verstehen/nicht verstehen sondern um ZÜGIG verstehen/nicht verstehen. Da sind Kommentare immer hilfreich. Natürlich kann man auch übertreiben, aber ich wüsste nicht warum hier ein kurzer Hinweis der den Begriff "Off-the-end iterator" enthält hinderlich bzw. Wahnsinn sein sollte.
Zum zügig verstehen sind kommentare sogar hinderlich
du musst nicht wissen was ein off-the-end-iterator ist um den code zu verstehen. er liest von cin und accumuliert bis irgendwas eintritt, endzeichen, EOF, etc. das ist ja egal.
Wenn du wissen willst wie lange er accumuliert, dann schaust du genauer hin und siehst "istream_iterator<int>()". Das ist ein leerer iterator, also kann es sich nur um EOF handeln - denn alle anderen Situationen würden einen bestimmten iterator verlangen.
Wenn du ehrlich bist freust du dich auch, wenn in Quelltexten die dir unbekannte Bibliotheken verwenden ein paar Hinweise stehen, damit du das einigermaßen flüssig lesen kannst. Komm schon. Gib es zu ...
Mich interessiert in kommentaren aber keine doku ala
++i; //i wird um eins erhöhtin kommentare haben die sachen zu stehen die im code nur indirekt oder garnicht stehen. zB warum accumuliere ich hier die werte von stdin? warum stdin? warum accumulieren? warum bis eof gehen? das sind die fragen die mich interessieren.
-
Simon2 schrieb:
Meintest Du
"Ich finde das Kommentieren von Algorithmen und Bestandteilen ..."Ja, ist nachgetragen - denken und schreiben klafft doch manchmal auseinander
-
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 QuelltextMusst 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öhtIch 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.
-
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.
-
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.
-
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
-
@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.
-
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...
-
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.
-
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.
-
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).
-
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 QuelltextNach 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 Quelltextwow.
übersichtlich.
