AW: Quellcode Kommentieren
Hallo,
also ich finde einen Kommentar nicht nutzlos. Ich benutze Teilweise sehr alten ASM- und C/C++ -Code den ich selber mal vor 10-15 Jahren oder noch älter geschrieben habe und dank des Kommentars bin ich schnell in der Lage zu sehen wie ich die Routinen einsetzen kann und wie sie getestet worden sind. Und sprechende Namen für Proceduren / Function sprechen heute, aber wie sprechen sie in 10 Jahren? Man ist nicht mehr im Thema und dann erscheint der Ablauf innerhalb der Procduren auch nicht mehr so klar das ist jedenfalls meine Erfahrung. Bis bald Chemiker |
AW: Quellcode Kommentieren
Hallo,
auch ich bin der Meinung, dass JEDE Methode kommentiert sein muss. Spätestens, wenn sich jemand in etwas einarbeiten soll, ist das wichtig. Allerdings ist der Kommentar der Methode ein Sache, weit wichtiger sind aber die Parameter- und Returnwertbeschreibung. Ich halte mich übrigens an die Syntax von DelphiCode2Doc. Bsp:
Delphi-Quellcode:
Ich bin selber mal in die Falle getappt, dass ich auf -1 geprüft habe, statt auf <1
{*
vergleicht 2 Strings, ohne Groß- und Kleinschreibung zu beachten @param S1 erster String @param S2 zweiter String @return <1 S1<S2, >1 S1>S2, =0 S1=S2 } function CompareText(const S1, S2: String): Integer; Dass man aus diesen Kommentaren auch schön eine Dokumentation rausziehen kann, also die Code-Beschreibung nicht doppelt schreiben muss, ist ein angenehmer Zusatznutzen. Heiko Heiko |
AW: Quellcode Kommentieren
Zitat:
Zitat:
|
AW: Quellcode Kommentieren
Zitat:
Wir haben z.B. unsere API mit 1-2 Sätzen im Code dokumentiert und sehr ausführlich im internen Wiki. Die Code-Dokumentation dient (in VS) dazu, beim Code-Proposal gleich was sehen zu können, auch wenn die Kommentare z.T. echt überflüssig sind, denn sowohl Methoden- als auch Parameternamen sind selbsterklärend. Man erkennt zwar, das eine Exception geworfen wird (kein Rückgabewert), aber trotzdem ist es besser, man sieht es in der Code-Dokumentation der Methode. Das hat imho nichts damit zu tun, den Code durch Kommentare verständlicher machen zu wollen, denn das geht eigentlich immer schief und ist der falsche Weg. Zitat:
Zitat:
Eine Methode besteht bei mir neben Zuweisungen und Methodenaufrufen aus entweder einer Schleife oder einem if-Statement, wobei ich selbst hier noch awäge, ob die Kontrollstruktur nicht doch in eine eigene Methode kommt. In jedem Fall löst die Methode genau eine Aufgabe, die sich im Namen wiederspiegelt. Verschachtelungstiefe maximal 2-4, wobei das Abstraktionsniveau gleich bleibt. Das verstehe ich auch noch nach 10 Jahren (und ich mach das seit 30), denn der Code ist -bis auf die unterste Ebene, ausschließlich englisch. Grammatikalisch nicht immer 100% korrekt, aber verständlich. Ich muss ja nicht den gesamten Code, also bis zur untersten Stufe sehen. Es reicht doch, wenn ich verstehe, was die Methode macht:
Delphi-Quellcode:
Das versteht jeder auch nach 50 Jahren noch. Wie genau ein Byte in ein 'Hex' konvertiert wird, ist ja schnurz. Ich weiß, was ein Byte ist, ich weiß, was ein 'Hex' ist. Ich weiß, was 'Convert' bedeutet.
Function ConvertBytesToHexString (const bytes : TByteArray) : String;
Begin Result := ''; foreach byte in bytes do Result := Result + Convert.ToHex(byte); End; Beim Coden stelle ich mir immer die Frage:"Was für ein Gesicht macht mein Kollege, wenn er meinen Code liest?" und "Würde ich anfangen, zu stottern oder zu rudern, wenn ich ihm meinen Code erklären müsste?". Denn das muss ich, wenn er Schrott ist. Da ich meine Ruhe haben will, mach es lieber gleich so, das alles vorbildlich ist. Mäckeln tun die dann immer noch (liegt wohl in der Natur des Programmierers)x, aber dann auf sehr hohem Niveau: "Sollte die Methode nicht 'ConvertByteArrayToHexString' heißen? oder (hier) "Die Methode ist an der falschen Stelle: Verschiebe sie als statische Methode in unseren Converter". So macht programmieren Spaß, denn man pusht sich gegenseitig immer höher. |
AW: Quellcode Kommentieren
Zitat:
|
AW: Quellcode Kommentieren
Zitat:
Bei solchen Ideen ist es aber wirklich nicht auszuschließen Zu der Frage ob kommentieren Sinnvoll ist: Ja, wenn es sich um schwer zu verstehenden Sachen handelt, wie zum Beispiel ein Algorithmus. Bei simplen Aufgaben wie 2*2 ist es nicht empfehlenswert, da der Code unübersichtlich wird |
AW: Quellcode Kommentieren
Zitat:
Delphi-Quellcode:
Hier sehe ich sofort, daß der Code geändert wurde. Und vorallem wieso etwas im Code geändert wurde. Fällt sofort in's Auge. Wie würde das im CVS aussehen?
Procedure ZeigMalWas;
begin // 10.10.2012 - E-Mail von Meyer - Will ein Blinken im Sekundentakt. // LassBlinken(1); // 20.11.2012 - E-Mail von Müller - Blinken zu hektisch. Auf Wunsch nur alle 2 Sekunden. // LassBlinken(2); // 20.03.2013 - Telefonat mit Meyer - Vertrieb hat sich durchgesetzt. Blinken 2 mal pro Sekunde. LassBlinken(0.5); end; |
AW: Quellcode Kommentieren
Zitat:
|
AW: Quellcode Kommentieren
Zitat:
|
AW: Quellcode Kommentieren
Zitat:
Diese Information als Kommentare in den Code zu setzen ist nur in wenigen Ausnahmen sinnvoll, und entsprechend spärlich sollten diese Kommentare verwendet werden. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 21:50 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz