Hallo zusammen,

für mich gehört in einem perfekten Sourcecode jede Code-Zeile, die nicht trivial ist, d.h. in der nicht bloß eine Variableninitialisierung oder eine Wertzuweisung o.Ä. stattfindet, dokumentiert. In diesem Sinne kann man eigentlich garnicht genug Kommentare schreiben, und das Argument, zu viele Kommentare würden einen Sourcecode unübersichtlich machen, sehe ich nicht ein. Das mag vielleicht so sein, wenn man mit notepad.exe programmiert, aber wer tut das heutzutage noch ?

Hallo herbivore,

ich kann Deinen Punkten nicht oder nur begrenzt zustimmen.

•Es fängt damit an, dass es (Arbeits-)Zeit kostet, Kommentare zu erstellen.

Einen unkommentierten Fremdcode nachvollziehen zu müssen ist ab einer gewissen Mindestkomplexität sicherlich Zeit- und damit auch Kostenintensiver.

•Dann müssen Kommentare an Codeänderungen angepasst werden, die müssen also aktuell gehalten werden.

Das stimmt natürlich, ist aber kein "Nachteil eines Kommentars". Die Alternative, keine Kommentare zu nutzen ist sicherlich nicht besser als der unbestrittene Fakt, dass Kommentare auch gepflegt werden müssen.

•Das kann vergessen werden und zu Inkonsistenzen führen.

Stimmt, aber von vorneherein keine Kommentare zu machen kann dagegen dazu führen, dass ein Entwickler tage- oder wochenlang versucht einen Code nachzuvollziehen, der mit einem Kommentar sofort klar wäre.

•Wenn die Änderungen nicht vergessen werden, kosten sie erneut Zeit.
•Je mehr und je längere Kommentare existieren, desto mehr Zeit kosten die Aktualisierungen und desto eher übersieht der Änderer notwendige Aktualisierungen.

siehe Punkt 1 - dass es Zeit kostet und gepflegt werden muss ist klar, aber mit dieser Argumentation könnte man auch sagen "Programmieren ist ein Nachteil" oder "Zähne putzen ist ein Nachteil".

•Selbst wenn Kommentare keine überflüssigen Informationen enthalten, können sie den Code auseinander ziehen/reißen und dadurch die Übersichtlichkeit verringern.

Ich bleibe dabei, dass ordentlich formatierte Kommentare einen Code nicht unübersichtlicher machen. Das passiert nur wenn man es gezielt darauf anlegt wie
Winsharp93 es oben in einem Extrembeispiel gezeigt hat.

•Selbst mit guter Absicht und Sorgfalt erstellte Kommentare können inhaltlich falsch oder missverständlich formuliert sein und dadurch schaden.

Diesen Punkt lasse ich bedingt gelten, wobei es auch hier nicht um einen Nachteil des Kommentierens geht, sondern um die Kommunikationsfähigkeit des Mitarbeiters. Dieses Problem besteht bei allen Arbeitsabläufen, bei denen zwei oder mehr Personen miteinander kommunizieren müssen.

•Selbst in mit guter Absicht und Sorgfalt erstellten Kommentare können gerade die Informationen fehlen, die ein späterer Leser mit einem anderen Erfahrungshintergrund benötigt.

Worin liegt dann der Nachteil im Vergleich dazu gleich garkeinen Kommentar zu hinterlegen ?

Also throw new Exception ist Murks, wie ja bereits ausreichend in diesem Thread gesagt wurde. Wenn Du unbedingt ein AutoresetEvent nutzen willst, dann nimm die WaitOne() Überladung, die einen Timeout-Parameter akzeptiert um die Blockade nach einer geeigneten Zeit X abzubrechen. Das in Verbindung mit dem Vorschlag von xxMUROxx sollte schonmal dazu führen, dass Du die Schleife gezielt sauber beenden kannst.

Ist ja klar, dass Du nur Bahnhof verstehst, der Klassenname sagt ja auch nicht aus, wie man damit arbeiten musst. Hast Du denn mal nach den genannten Stichworten gesucht ? Oder willst Du jetzt eine fertige Lösung haben ?

Naja, Du kannst Deine Methode ja auch mit Brainfuck.NET programmieren, dann kann den ach so simplen Code auch niemand mehr entziffern. Will sagen, Dein Beispiel ist albern... wenn jemand anfängt zu kommentieren, was ein Semikolon bedeutet, gehört er eher ans Fließband als vor einen PC. Und bei einem Kommentar für jedes Wort eine eigene Zeile zu benutzen oder alle Kommentare in den Code rein zu packen ohne Zeilenumbruch hat eher mit Sabotage als mit konstruktiver Arbeit zu tun.

Genausogut könntest Du den Code selbst, der ohne Kommentare auskommt, so beschissen formatieren und mit sinnlosen Operationen auffüllen, dass Du Deine Argumentation umkehren kannst.

Vielleicht liegt es dran dass der BOOL in C eine andere Größe hat als in C#? [...] Versuch mal einen int zurückzugeben [...]

Wenn es C ist nutzt ein Int nichts, dann müsste man stattdessen schon MarshalAs(UnmanagedType.I2) verwenden.

Was ist daran Gefrickel ? Das ist ein 3-Zeiler bei der der Aufruf einer Methode der Form-Klasse demonstriert wird. M$ frickelt ja oft und gerne, aber das hier finde ich noch ganz simpel realisiert.

Wenn Du schon Access benutzt, lad Dir Deine Datensätze in ein Dataset und Weise das Dataset einem Datagrid Control zu. Schon bekommst Du die Datensätze angezeigt.

Zum Zugriff auf eine Access-Datenbank solltest Du mal nach ADO.NET googeln, da gibt es massig Tutorials. Im Übrigen wird der DB-Zugriff über ADO standardisiert, so dass Du je nachdem ob Du Access, SQL oder was auch immer verwendest, meist nur noch den ConnectionString entsprechend anpassen musst.

Es gibt meiner Meinung nach keinen einzigen Grund, der dafür spricht, Kommentare einzusparen. Je mehr Kommentare, desto besser. Selbst wenn es nur Stating-The-Obvious ist, für den einen mögen Sachverhalte offensichtlich sein, für einen anderen, der einen Fremdcode vorgesetzt bekommt, vielleicht nicht. Hingegen sehe ich keine Nachteile in mehr Kommentaren, im schlechtesten Fall bringt ein Kommentar keinen Mehrgewinn, dann schadet er aber auch nicht.

Leider suchen viele immer nach Argumenten, warum Kommentare schlecht sind oder warum Kommentierung überflüssig ist, das liegt dann aber in 100% der Fälle an der Faulheit der Leute, die aber dann gern am Firmenstammtisch über den Code von jemand anderem herziehen "Voll scheiße, alles endlos verzweigt, nix kommentiert... wie soll man da denn durchblicken..."