Organisation von Code

David_pb schrieb:

Unsinn, die Kommentare werden hier ja nicht zur Kommentierung verwendet, sondern teilen das Interface logisch auf und dienen als Hinweis für (u.A.) andere Entwickler die Struktur beizubehalten und das ist keinenfalls überflüssig.

Interface?!? Das sind Kommentare in einer Funktion, sie kommentieren die einzelnen Rechenschritte. Ich hab mal gelernt, dass Kommentare so weit wie möglich vermieden werden sollen, vielmehr sollen Namen (für Klassen/Methoden/Variablen) sprechend sein.
Außerdem finde ich es fragwürdig, wenn Kommentare dem Entwickler vorschreiben sollen, wie ein Algorithmus zu funktionieren hat.

In dem von dir zitierten Beispiel sind die Kommentare mehr als überflüssig.

Und die Unterteilung des OP kann man sich schenken, wenn man im Interface zu allererst Konstruktoren, dann den public Teil (für Verwendung der Klasse), dann protected (für Ableiten), dann private angibt. So sollte gewährleistet werden, dass jede Interessengrupee schnellstmöglichst ans Ziel gelangt. Rein ohne Kommentare.

pumuckl

David_pb schrieb:

Unsinn, die Kommentare werden hier ja nicht zur Kommentierung verwendet, sondern teilen das Interface logisch auf und dienen als Hinweis für (u.A.) andere Entwickler die Struktur beizubehalten und das ist keinenfalls überflüssig.

Und jeder Entwickler der sich den Code länger als eine Sekunde anschaut sieht die Unterteilung auch ohne Kommentar.

Icematix

Niemals C++-Sprachelemente wie "{" durch defines ersetzen.

David_pb

@ loks & toter hahn: Erstmal lesen und dann schreiben...

pumuckl schrieb:

David_pb schrieb:

Unsinn, die Kommentare werden hier ja nicht zur Kommentierung verwendet, sondern teilen das Interface logisch auf und dienen als Hinweis für (u.A.) andere Entwickler die Struktur beizubehalten und das ist keinenfalls überflüssig.

Und jeder Entwickler der sich den Code länger als eine Sekunde anschaut sieht die Unterteilung auch ohne Kommentar.

Erfahrungsgemäß ist das aber leider nicht der Fall.

It0101

wir reden hier von absolut offensichtlichem Sourcecode, der nicht kompliziert verschaltet ist und auch keine 2,3516 mio Unterfunktionen aufruft.

Ich handhabe das immer so, dass ich vor einem größeren komplexen Block von Funktionalität einige Zeilen Kommentare schreibe, die grob verdeutlichen sollen, was der folgende Block macht. Das reicht meiner Meinung nach.

Funktionen bekommen natürlich auch immer einen Kommentar, der die Aufgabe der Funktion beschreibt. ( möglichst einzeilig )

pumuckl

It0101 schrieb:

Funktionen bekommen natürlich auch immer einen Kommentar, der die Aufgabe der Funktion beschreibt. ( möglichst einzeilig )

Wenn die Funktion einen genügend aussagekräftigen Namen hat, erübrigt sich selbst das häufig.

Ich handhabe das immer so, dass ich vor einem größeren komplexen Block von Funktionalität einige Zeilen Kommentare schreibe, die grob verdeutlichen sollen, was der folgende Block macht. Das reicht meiner Meinung nach.

Wenn du den komplexen Block in eine eigene Funktion mit srechendem Namen auslagerst, erübrigen sich häufig auch die Block-Erläuterungen.

David_pb schrieb:

@ loks & toter hahn: Erstmal lesen und dann schreiben...

Dann solltest du mal erst ordentlich zitieren. Ein Fullquote hindonnern und allgemein über "hier" sprechen (was jeder auf den zitierten Code-Abschnitt bezieht), gleichzeitig von "Interface aufteilen" und "Struktur beibehlaten" reden, wo nur ne simple Funktion zu sehen ist.
Wunder dich also nicht...

Außerdem springt - dank Syntax-Highlighting - ein "public" oder "private" sofort ins Auge. Da braucht man nicht noch nen verschlimmbessernden Kommentar.

Und wenn von "anderen Programmierern" die Rede ist, ist es ein größeres Projekt, und die haben eine "Coding-Guideline". Wer gegen die Guideline verstößt kann abgemahnt und später im svn (oder anderes Versionsverwaltungssysetm) Schreibrechtentzug bekommen.

Es gibt (fast) immer effektivere Lösungen als Kommentare im Source.

Tyrdal

Anderes Thema. Un -> Ungarische Notation. Jetzt kannste googlen.

It0101

pumuckl schrieb:

Ich handhabe das immer so, dass ich vor einem größeren komplexen Block von Funktionalität einige Zeilen Kommentare schreibe, die grob verdeutlichen sollen, was der folgende Block macht. Das reicht meiner Meinung nach.

Wenn du den komplexen Block in eine eigene Funktion mit sprechendem Namen auslagerst, erübrigen sich häufig auch die Block-Erläuterungen.

Im schlimmsten Fall hat man dann 20 weitere private Funktionen in der Klasse, die nur einmal in einer anderen Funktion aufgerufen werden.

Das mache ich echt nur, wenn die Funktion wirklich zu groß ist. Funktionen versuche ich, wenn möglich immer komplett im sichtbaren Bereich zu halten. D.h. wenn ich die Hälfte der Funktion nicht ins Fenster kriege, wird es zeit aufzuteilen

Nexus

It0101 schrieb:

Ich handhabe das immer so, dass ich vor einem größeren komplexen Block von Funktionalität einige Zeilen Kommentare schreibe, die grob verdeutlichen sollen, was der folgende Block macht. Das reicht meiner Meinung nach.

Funktionen bekommen natürlich auch immer einen Kommentar, der die Aufgabe der Funktion beschreibt. ( möglichst einzeilig )

Handhabe ich weitgehend gleich.

Mehrzeilige Funktionskommentare à la Javadoc sind mir zu mühsam für alltäglichen Code (für Dokumentationen von Bibliotheken können sie nützlich sein). Aber oft überschneiden sich allgemeine Beschreibung, Parameter und Rückgabetyp, sodass zwei Drittel des Kommentars redundant ist.

pumuckl schrieb:

Wenn du den komplexen Block in eine eigene Funktion mit srechendem Namen auslagerst, erübrigen sich häufig auch die Block-Erläuterungen.

Teilweise schon, aber so einfach ist das nicht immer. Oft macht eine Funktion kompliziertere Dinge, die nicht in einen brauchbaren Bezeichner gefasst werden können. Oder es gibt besondere Hinweise, die zu beachten sind. Irgendwo bringt es auch nichts mehr, weiter aufzuteilen, dann schreibt man lieber einen Kommentar hin, dafür hat die Funktion eine richtige Aufgabe. Ich stehe zumindest nicht auf zig kleine Zweizeilerfunktionen, von denen man jeweils 5 gemeinsam anschauen muss, bis überhaupt ein abstraktionswerter Gedanke ersichtlich ist.

Tyrdal schrieb:

Anderes Thema. Un -> Ungarische Notation. Jetzt kannste googlen.

Zur UN habe ich mal etwas geschrieben.

Tyrdal

Das Problem war einfach, daß die Leute UN falsch verstanden haben. Wenn man nicht den Typ sondern die Aufgabe kodiert machts manchmal Sinn. Dann ist es quasi Bestandteil des sprechenden Namens.

It0101

Da hat er recht.
Die ungarische Notation haben einige in den falschen Hals bekommen.

Zitat: Wikipedia

Es geht also nicht so sehr darum, ob eine Variable Ganzzahl oder Kommazahl ist, sondern ob es sich um einen Zähler handelt, eine Koordinate auf dem Bildschirm, einen Index in einem Array o. ä.

http://de.wikipedia.org/wiki/Ungarische_Notation

Und das macht aus meiner Sicht sehr wohl Sinn.

Kóyaánasqatsi schrieb:

Die Kommentare sind völliger Quatsch. Das CRealWindow eine Klasse ist, sehe ich, also was bringt mir dann noch der Kommentar? Zeile 22 und 28 sind auch unnütz. Nicht beschreiben was es macht, sondern warum es was macht.

1337!!!

Die einzigen Kommentare die nutzlos und völliger Quatsch sind, sind deine...

Wenn sich jemand so besser auskennt, soll er´s machen.

adsfadf schrieb:

Kóyaánasqatsi schrieb:

Die Kommentare sind völliger Quatsch. Das CRealWindow eine Klasse ist, sehe ich, also was bringt mir dann noch der Kommentar? Zeile 22 und 28 sind auch unnütz. Nicht beschreiben was es macht, sondern warum es was macht.

1337!!!

Die einzigen Kommentare die nutzlos und völliger Quatsch sind, sind deine...

Wenn sich jemand so besser auskennt, soll er´s machen.

laberkopp.. vlt hätteste mal die anderen beiträge lesen sollen

Bashar

CodeThatDocumentsItselfSoWellItDoesNotNeedComments

Tyrdal

Also ehrlich gesagt sind mir passende überlange Bezeichner lieber als un- oder falsch kommentierte Kryptoabkürzungen. In Zeiten von code completion ist die Länge der Namen für die Tipparbeit ja nur noch mäßig relevant.

volkard

It0101 schrieb:

Bei mir sieht es so ähnlich aus, wie bei DeepCopy.
Nur dass "private", "public" und "protected" bei mir nicht eingerückt werden.
Die Funktionen und Variablen sind immer 1 Tab ( 4 Zeichen ) eingerückt.
Wenn es viele Funktionen sind, mach ich das auch manchmal so:
inline void         Funktion1  ( int a, int b )        { return bla; }
       unsigned int Funktion2  ( int c );
       double       Funktion22 ( int d, int e, int f );
Also sozusagen formatiert geschrieben ( wobei die "inliner" eigentlich bei mir immer nebeneinander liegen. )
Aber das ist eine reine Frage der Code-Ästhetik.

Wie     kommen        Leute  nur    auf 
solche  ausgesprochen dummen Ideen? Die
Einheit des           Sinns  ist    doch 
eher    die           Zeile  und    nicht
die     Spalte.

volkard

It0101 schrieb:

Und das macht aus meiner Sicht sehr wohl Sinn.

Da hast Du was falsch verstanden. UN taugt bei Krüppelsprachen wie C was. Wir können gewisse Informationen stattdessen besser und compilergeprüft in die Typen stecken. Und da, wo das sich nicht bewährt, bewährt sich UN auch nicht.

Tyrdal

Du bist immer noch auf dem falschen, dem Typendampfer. Un war ursprünglich nicht für Typen und hat daher auch nichts mit einem Typsystem zu tun.

volkard

Tyrdal schrieb:

Du bist immer noch auf dem falschen, dem Typendampfer. Un war ursprünglich nicht für Typen und hat daher auch nichts mit einem Typsystem zu tun.

Ich habe es ausprobiert. Die richtige Version, wo man mit Präfixen zum Beispiel die x-Koordinaten von den y-Koordinaten trennt und bei xFoo=(xBar-yMal)/2; sofort weiß, daß das Unfug ist. x*y geht ja, aber x+y ist fast immer falsch. Ich habs auch mit Typen gemacht. Schon vor 10 Jahren. Und daher weiß ich, daß die Ungarische Notation nicht sachdienlich ist.