Eure besten Quellcode Kommentare...

[r2c2]

Zitat von Tonic1024:

Diese nutzlosen und verwirrenden Kommentare hab ich mir in längerem Code, zusammen mit zusammenhängenden Blöcke umschlossenen von doppelten Leerzeilen (hier grad nicht) und horizontalen Minus-Linien (also //-----) an "Inhalts-Umbrüchen", angewöhnt und meine Kollegen haben sich das teilweise abgeschaut.

Das ist ein Zeichen dafür, dass deine Methoden zu lang sind. "Inhaltliche Trennungen" macht man am besten durch syntaktische Trennungen. Neue Methoden, neue Klassen, etc. Und damit sind die Ganze Kommentiererei auch schon überflüssig. Darf ich ein Buch empfehlen? Clean Code.

[Headbucket]

Wenn mehrere Leute am selben Code arbeiten:

//FreeAndNil(td^.tr[2]); //2 Kanal brauchen wir nicht //brauchen wir doch //To-Do

Gruß
Headbucket

[Tonic1024]

Zitat von r2c2:

Das ist ein Zeichen dafür, dass deine Methoden zu lang sind.

Das ist reine Theorie.

Wenn man zum Beispiel einem Webserver einige Aufgaben gibt, so steht der Code im Indys OnCommandGet Routine. Wenn man jetzt hin geht und die individuelle Parameter Detektion in eine Funktion auslagert und jede einzelne Aufgabe in eine separate Funktion auslagert braucht man dennoch die selben 10 Zeilen (okay, sehr ähnliche 10 Zeilen) im Code wieder und wieder und wieder untereinander. Ein fürs Auge leicht wieder zu findender grüner "Eyecatcher" ist beim scrollen sehr hilfreich. Die Länge der Methode ist damit, unabhängig davon ob man ein Buch gelesen hat oder nicht, direkt abhängig vom Funktionsumfang des Servers. Nur mal ein Beispiel.

Oder ein Gegensätzliches. Wenn man komplexe aber dennoch überschaubare Aufgaben (z.B. Stream empfangen, manipulieren und weiterleiten) solange in separate Routinen aufteilt bis kaum noch ersichtlich ist welche Nebenwirkungen eine Änderung in einer Sub-Sub-Routine hätte ist das auch nicht besonders übersichtlich.

Ich wundere mich warum hier so eine Abneigung gegen Kommentare mit optischem Charakter herrscht. Ich hab noch beigebracht bekommen über jede Routine einen Funktionsbeschreibung, Parameterdefinition, Precondition und Postcondition zu tippen.

[p80286]

Zitat von Tonic1024:

Ich wundere mich warum hier so eine Abneigung gegen Kommentare mit optischem Charakter herrscht. Ich hab noch beigebracht bekommen über jede Routine einen Funktionsbeschreibung, Parameterdefinition, Precondition und Postcondition zu tippen.

Wie üblich gilt auch hier "Es kommt darauf an".
Manchmal sind selbst Kommentare wie

Code:

a:=b shr 1; // div 2

durchaus angebracht.

Gruß
K-H

[himitsu]

Zitat von p80286:

Manchmal sind selbst Kommentare wie

Code:

a:=b shr 1; // div 2

durchaus angebracht.

Wenn b ein Integer ist, dann wäre der Kommentar falsch.
ber ja, hier hättest du Recht.
Wobei der Kommentar nichts doppelt sinnlos erklärt, sondern das shr erklärt.

[Valle]

Kommentare können durchaus äußerst sinnlos werden.

An meiner Uni gibt es bei der Abgabe der Aufgaben zur Programmieren-Vorlesung eine automatische Überprüfung auf Stil und Kommentierung. Das endet dann in solchen Stilblüten, damit der Automat fehlerfrei durchläuft:

(Dabei sei hervorgehoben, dass nicht nur die Kommentierung jedes einzelnen Enum-Elements sinnlos ist, sondern auch diese inline-Versionierung und Angabe des Autors. Was um Himmels Willen soll der Quatsch denn?!)

Code:

/**
 * Eine einfache Definition eines Wochentags.
 * @version 1.0
 * @author Valentin Voigt
 */

enum Weekday {
   
   /**
    * Sonntag   
    */
   
   SUNDAY,
   
   /**
    * Montag
    */
   
   MONDAY,
   
   /**
    * Dienstag
    */
   
   TUESDAY,
   
   /**
    * Mittwoch
    */
   
   WEDNESDAY,
   
   /**
    * Donnerstag
    */
   
   THURSDAY,
   
   /**
    * Freitag
    */
   
   FRIDAY,
   
   /**
    * Samstag
    */
   
   SATURDAY
}

[Namenloser]

Zitat von Valle:

Kommentare können durchaus äußerst sinnlos werden.

An meiner Uni gibt es bei der Abgabe der Aufgaben zur Programmieren-Vorlesung eine automatische Überprüfung auf Stil und Kommentierung. Das endet dann in solchen Stilblüten, damit der Automat fehlerfrei durchläuft:

(Dabei sei hervorgehoben, dass nicht nur die Kommentierung jedes einzelnen Enum-Elements sinnlos ist, sondern auch diese inline-Versionierung und Angabe des Autors. Was um Himmels Willen soll der Quatsch denn?!)

Der Code hat mich gleich an die Programmieren-Vorlesung hier erinnert... dann ist mir aufgefallen, dass du ja auch in Karlsruhe studierst

Als ich das erste (und letzte ) mal im Programmieren-Tutorium war und der Tutor uns zeigte, wie man jedes einzelne Klassenmember mit einem dreizeiligen Kommentar versehen soll, dachte ich erst, es wäre ein Scherz

Naja, aktuell mache ich hier dieses Softwarepraktikum (nicht am KIT), und da ist jetzt von den Coding Conventions gefordert, zwischen alle Funktionsdefinitionen solche Trennlinien zu machen:

//============================================================================

Auch sehr sinnlos... wobei der Rest recht vernünftig ist, das macht es für mich noch irritierender.

[Meflin]

Zitat von Namenloser:

Naja, aktuell mache ich hier dieses Softwarepraktikum (nicht am KIT), und da ist jetzt von den Coding Conventions gefordert, zwischen alle Funktionsdefinitionen solche Trennlinien zu machen:

//============================================================================

Wie dumm ist das denn? Vor allem, wenn man bedenkt, dass ein durchschnittlicher Editor sowas heutzutage von selbst einfügen anzeigen kann, sofern man es denn haben will

[Mikkey]

[QUOTE=himitsu;1239686]

Zitat von p80286:

Wobei der Kommentar nichts doppelt sinnlos erklärt, sondern das shr erklärt.

Sinnlos is m.E. eher die Anweisung selbst. Wenn ich durch zwei teilen will (was laut Kommentar ja die Absicht ist), dann sollte ich das auch so schreiben;

Code:

a := b div 2;

Optimierung im Algorithmus mag ja sinnvoll sein, aber ob eine Shift-Operation schneller als die Teilungsoperation ist, sollte man dem Compiler überlassen.

Es mag aber durchaus geeignetere Beispiele geben, wo diese Art von Kommentar sinnvoll ist.

[Memnarch]

Zitat von Mikkey:

Code:

a := b div 2;

Optimierung im Algorithmus mag ja sinnvoll sein, aber ob eine Shift-Operation schneller als die Teilungsoperation ist, sollte man dem Compiler überlassen.

Yep, ein shr ist in dem Fall schneller als ein DIV. Liegt daran, das eine DIV-Operation(welche direkt in der CPU integriert ist) sehr aufwendig ist, da sie im allgemeinen an das mathematische Problem rangeht.(von +-*/ ist / bzw DIV die langsamste)

mit shr nimmst du bei Dvisionen durch eine Zweierpotenz(2, 4, 8, 16) eine unkomplizierte Abkürzung. ein shr ist vergleichweise schnell erledigt auf der CPU. Die logik dahinter ist einfach unkomplizierter.

EDIT: Und falls jemand fragt: Nein, in einer normalen Anwendung ist das komplett Hupe, ob man div oder shr nimmt(hier würde ich der Lesbarkeithalber eher div empfehlen). Aber mein Softwarerenderer hat's mir gedankt

Grüße
Memnarch