Organisation von Code

[adsfadf]

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.

[adsasdasd]

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.

[Nexus]

It0101 schrieb:

inline void         Funktion1  ( int a, int b )        { return bla; }
       unsigned int Funktion2  ( int c );
       double       Funktion22 ( int d, int e, int f );

Hab ich wohl übersehen, ganz so ähnlich wie du formatiere ich den Code dann doch nicht.

Das Problem bei diesem Ansatz ist, dass du extrem unflexibel bist und bei einem const std::map<bla, std::string>& -Parameter die Spalten unnötig in die Länge ziehst. Klar, typedef wäre eine Möglichkeit, aber oft lohnt sich ein typedef deswegen nicht oder muss trotzdem eine gewisse Länge haben, um noch etwas auszusagen.

Bei Rückgabetypen finde ich es jedoch wirklich übersichtlicher - aber da trenne ich all die zusätzlichen Angaben wie virtual nicht vom eigentlichen Typen. Aber so eine ganz universelle, ideale Möglichkeit erschliesst sich mir da nicht.

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.

UN wird heute aber meist mit Typen in Verbindung gebracht. Wir können den Codestil, der Typen per Präfix wie C für Klassen und p für Zeiger bezeichnet, auch gerne anders nennen, die Problematik bleibt die gleiche.

[It0101]

Also ich verwende UN insofern, dass ich versuche, den Variablen sprechende Namen zu geben: Also was tut diese Variable / was enthält sie. Aber das tun doch hier die meisten.

@Volkard: hass mich nicht, weil ich anders bin

[It0101]

Das Problem bei diesem Ansatz ist, dass du extrem unflexibel bist und bei einem const std::map<bla, std::string>&-Parameter die Spalten unnötig in die Länge ziehst. Klar, typedef wäre eine Möglichkeit, aber oft lohnt sich ein typedef deswegen nicht oder muss trotzdem eine gewisse Länge haben, um noch etwas auszusagen.

Ich weiß... ich mach es auch nur in seltenen Fällen. Scheinbar kam das so rüber, als würd ich das immer so machen

[jesus was black]

Ich bevorzuge diesen Stil : http://www.appinf.com/download/CppCodingStyleGuide.pdf und bin ein sehr großer fan von typedef, benutze ich fast immer für jeden Container. Also mag ich auch diesen Stil, obwohl ich ihn nicht oft benutze:

// in some class
typedef std::map <
                      int , string
                 > TComplexInformations;

Also

<

 >

Für jeden Container, der mehr als ein arg nimmt. Natürlich benutze ich auch fast immer typedef für die Iteratoren, d.h

typedef TComplexInformations::const_iterator TComplexConstItr;

TComplexInformations informations;

void foo(..)
{
   TComplexConstItr Itr;
   TComplexConstItr ItrEnd;

   Itr    = informations.begin();
   ItrEnd = informations.end();
   for (; Itr !=  ItrEnd; ++Itr )
   {

   }  

}

Also, kann ich z.B sowas nicht ausstehen:

enum bar
{
   longName = 5,
   longNameName = 7,
   longNameNameName = 12

   // Bei mir müssen die Member eines Enum immer "gleich" sein, d.h:

   longName         = 5,
   longNameName     = 7,
   longNameNameName = 12
} ;

@It0101

Ich finde, dass es nicht wirklich schön aussieht mit so vielen spalten. Aber jeder wie er es am besten für sich findet.

Gruß

[Tyrdal]

@volkard

zum Beispiel die x-Koordinaten von den y-Koordinaten trennt und bei xFoo=(xBar-yMal)/2; sofort weiß, daß das Unfug ist

Ich mein das so: int numPersons => num als Präfix kennzeichnet, daß es sich um eine Anzahl(number) von Personen handelt und nicht etwa um Instanzen der Klasse Person. Ob die Anzahl jetzt ein short, int, long oder sonstwas ist ist egal.

Anders gefragt wie heißen bei dir x und y Koordinaten, teta3F6 und retzu8x5?

[It0101]

Tyrdal schrieb:

Ich mein das so: int numPersons => num als Präfix kennzeichnet, daß es sich um eine Anzahl(number) von Personen handelt und nicht etwa um Instanzen der Klasse Person.

Ganz genauso meine ich das auch. Das ist die ursprüngliche UN. Und die praktiziere ich auch. Was ein Counter ist heißt irgendwie sowas wie "cnt", Anzahlen heißen "Num" oder "Anz", usw..

Nur wird man hier scheinbar manchmal ganz bewusst falsch verstanden

[volkard]

Tyrdal schrieb:

@volkard

zum Beispiel die x-Koordinaten von den y-Koordinaten trennt und bei xFoo=(xBar-yMal)/2; sofort weiß, daß das Unfug ist

Ich mein das so: int numPersons => num als Präfix kennzeichnet, daß es sich um eine Anzahl(number) von Personen handelt und nicht etwa um Instanzen der Klasse Person. Ob die Anzahl jetzt ein short, int, long oder sonstwas ist ist egal.

Ja, Typ ist weitgehend egal. Daß die Anzahl der Personen besser anzahlDerPersonen heißt, als nur personen, ist auch ganz ohne UN sonnenklar.

Tyrdal schrieb:

Anders gefragt wie heißen bei dir x und y Koordinaten, teta3F6 und retzu8x5?

Nö, sie täten heißen natürlich xTheta3F6 und yRetzu8x5, wenn ich UN benutzte.