Eure besten Quellcode Kommentare...

[Mikkey]

Ich finde da ebenfalls nichts Schlimmes dran.

An der Uni habe ich Algol-68 gelernt (einer der Vorläufer von C) und finde es ausgesproche schade, dass die dort erfundene Art der Klammerung kein Allgemeingut geworden ist:

Code:

if ... fi
do ... od
case ... esac

Im Gegensatz zum kryptischen

Code:

x = (a==b?c:d);

[mcinternet]

Habe mich monatelang in ein größeres Projekt eingearbeitet, welches mal in D7 geschrieben worden ist und dieses nach XE3 portiert.
Quellcode gesamt über 30.000 Codezeilen. Das gesamte Ding war nicht dokumentiert. 0 - nichts ...

Aber an einer (!!!) Stelle, wo der Ex-Kollege (welcher nat. nicht mehr greifbar ist) dynamisch einen (oder auch mehrere) Threads parallel erzeugt und unter Bedingungen(!!!) Speicher anfordert, steht ein großes: "UAAAAAARG"


Gruss

Mc

[himitsu]

Das compiler-unterstützte (b ? c : d) hätte einen Vorteil, gegenüber den IfThen-Funktionen vom Delphi.

Als Funktionsparameter wird c und d erstmal komplett ausgewertet, übergeben und dann erst in der Funktion wird entschieden was man nun braucht.
Beim ?: optimiert das der Compiler gleich so, daß nur der "benutzte" Teil ausgewertet wird.




PS: Was schön ist, ist Code, der immer schön erweitert wird, aber die Codeformatierung nicht mit angepasst wird.
z.B. die Einrückung nicht verschoben, wenn noch ein if+begin+end oder try+finally/except drum gekommen ist.

Ja, wenn man beim SVN die Leerzeichen nicht ignorieren lässt, dann mg das da zwar besser aussehen, aber der Code ist nach mehreren Änderungen absolut nicht mehr lesbar, egal wieviele Kommentare man da noch rein macht.

[BUG]

Zitat von Mikkey:

Code:

if ... fi
do ... od
case ... esac

Das finde ich wiederum gruselig (warum auch immer). In Bash-Scripte wird diese Notation genutzt.

Zitat von Mikkey:

Im Gegensatz zum kryptischen [...]

Man darf aber nicht vergessen, das C auch ein normales if hat

[Mikkey]

Ja stimmt, in Shellskripten gips das auch.

Das normale if kann man aber nur in alternativen Anweisungen verwenden, nicht in alternativen Daten.

Bei Algol68 ging nicht nur

Code:

x := (a=b|c|d);

sondern auch

Code:

(a=b|DoSomething()|DoSomethingElse());

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