Thema: "Naming Conventions" (mein Tip!)

[THX 1138]

bluecode schrieb:

ja und? Warum heißt die Klasse dann in dem Fall net einfach fuchs_rudel? Anstatt lebewesen_tier_***********_rudel_fuchs bzw. wie machst des überhaupt bei mehreren Basisklassen?

Füchse sind gar keine Rudeltiere...und wale keine fische

aber über style und konventionen lässt sich nicht streiten.
hab die profis unter euch schonmal gefragt, ob sie firmeninterne richtlinien haben, wär mal interessant wies im realen leben gehandhabt wird, und nicht in der theorie sein sollte.

[jemand ...]

Das ist mit Abstand die dämlichste Namenskonvention, die ich je gelesen habe, denn sollte es tatsächlich zu Namenskonflikten kommen (ob nun vom Compiler aus, oder einfach weil es möglicherweise weitere Programmierer verwirren könnte), dann geb ich halt einfach den voll qualifizierten Namen, inkl. Namespaces/Packages an.

[rapso]

wir haben eine StyleGuide an die wir uns halten müssen. Ich finde, dass es nicht so sonderlich wichtig ist, dass jemand einen Style verfolgt, sondern dass in einer Firma alle den selben Style schreiben damit man mit fremden source arbeiten kann. denn wenn man an einen style nicht gewöhnt ist, kann sich schneller ein fehler einschleichen.
wir haben die Styleguid am anfang noch öfter umgeändert, z.b. gab es nen prefix für primitive datentypen iCount, pstrName, aber das war eher störend.

was für das arbeiten öfters wichtig ist, ist zu wissen ob es eine normale var ist, ein pointer oder eine referenz, deswegen haben wir als prefixe für namen r oder p z.b. pTorte->Fuellung(); bzw rTorte.Fuellung(); und Torte.Fuellung(); für autopointer hat sich ap eingeschlichen.

Desweiteren haben wir prefixe für namespaces(N) structs(S) classen(C) abstrakteclassen/interfaces(I) und enums (E) um bei typennamen gleich erkennen zu können wie die anwendung ist.

wörter werden mit grossbuchstaben angefangen z.b. MeineKleineVariable; wenn es member sind, gibt es ein m_ prefix, früher gab es noch für parameter den zwang sie mit kleinbuchstaben anzufangen, aber das sah dann sehr inkonsisten aus und hatte keinen wirklich nutzen, denn ob es eine lokale variable oder ein parameter-by-value hat keinen unterschied eigentlich.

es ist verboten "magic numbers" zu nutzen, jede konstante muss deklariert werden, dabei kann man entwoder
enum{MEINEZAHL = 5}; oder
const unsigned int MEINEZAHL=5; schreiben.
bei aufzählungen von konstanten darf man unterstriche zur abtrennugn der aufzählung nutzen
const unsigned int SIZE_X=1024;
const unsigned int SIZE_Y=1024;

grundsätzlich dürfen namespaces nicht global geöffnet werden. der sourcecode muss ohne dokumentation lesbar sein, manche speziellen (überschaubaren) spezialitäten sollen mit nem kurzen hinweis versehen werden z.b.
x=x>>15;//div by 32768

interfaces müssen mit einem kommentar versehen sein die mit doxygen zu einer doku konvertierbar sind.

alle namen und schriftlichen dinge in zusammenhang mit code müssen english sein (z.b. namensgebung von varialben und funktionen)

naja, mehr fällt mir nicht ein, da gibt es noch so kleine dinge wie "const int& rValue" statt "const int &rValue" weil int& ein datentyp ist... aber oben stehen die dinge die mir am wichtigsten erscheinen

naja, wie bei allen dingen waren alle am anfang sehr dafür sich daran zu halten, mittlerweile schreibt die hälfte doch wieder code der ihnen den arbeitsplatz sichert.

btw. natürlich sind verpönte dinge wie this->, goto, magicnumbers, usw. verboten

[THX 1138]

danke man, dassist mal ein klares statement

rapso schrieb:

naja, wie bei allen dingen waren alle am anfang sehr dafür sich daran zu halten, mittlerweile schreibt die hälfte doch wieder code der ihnen den arbeitsplatz sichert.

ich schreib in meine protokolle auch nicht die feinen handling tipps, die über oder der zellen entscheiden *ganzfiesgrins*

[N00B37530894650]

was ist denn an this-> so falsch??

[akari]

Hallo

das this-> überflüssog ist, wenn Member der Klasse korrekt von Parametern getrennt benannt werden.

bis bald
akari

[rapso]

N00B37530894650 schrieb:

was ist denn an this-> so falsch??

falsch ist nichts daran, es ist nur überflüssig, genau so überflüssig wie

void SetLightCount(int C);
int  GetLightCount()const;
//oder
void SetLight0();
void SetLight1();
void SetLight2();
...

im vergleich zu

void LightCount(int C);
int LightCount()const;

man darf auch this->this-> verwenden, klar. das alles ist nichtmal ein warning wert. deswegen ist es ja auch eine "StyleGuide" und kein c++standard.

aber neben dem standard gibt es auch gewisse paradigmen an die man sich hällt, weil man ja irgendwie auf einen konsens kommen muss. einer dieser ist dass man code minimalistisch schreibt. das heißt "nicht mehr als nötig", das heißt nicht, dass es nur noch a000 bis a999 als vars gibt.
dabei ist this-> wirklich total überflüssig, es ist möglich (wie so viele anderen dinge auch), aber überflüssig... daneben ist es aus meiner persönlich sicht auch unschön die ganze zeit einen pointer auf sich selbst zu verwenden.

[Reyx]

Dieses ewige Gepräfixe kann ich nicht nachvollziehen: Ich benutze eigentlich nur noch die von Java bekannten Namenskonventionen: Einfach, unkompliziert und vor allen Dingen nicht gezwungen; die Variablen behalten ihre natürlichen Namen!

Wenn ich in einer statisch typisierten Sprache programmiere brauche ich keine Präfixe wie "i" für int oder "d" für Double, in einer dynamisch typisierten kann es mir hingegen wurscht sein, weil ich es eh ständig prüfen muss. Pointer, Referenz oder was auch immer ist mir dabei ziemlich egal: Ich bin noch nie in eine Situation gekommen, wo mein Code irgendwie missdeutlich in dieser Hinsicht war, bzw. ich einen etwaigen Defizit nicht durch einen kleinen Kommentar ausmerzen konnte.

"C" für Klassen halte ich für idiotisch, denn wenn ich die Klasse schon benutze, dann weiß ich auch, dass es eine ist. Anders herum zeigt mir meine IDE sofort an, wenn ich es z.B. mit einem enum zu tun habe -> Wozu also ein Prefix? Auch Namespaces sollten mir bekannt sein, wenn ich damit umgehe, bzw. macht es mir jede moderne IDE auch relativ einfach zu erkennen, ob ich mit 'ner variable vom Typ void* agiere oder doch nur einen Namespace unter einem bestimmten Namen erreiche. Klassenmember mit einem Prefix zu vershen halte ich für krank: Dadurch, dass sie einer Klasse untergeordnet werden, sind sie bereits eindeutig als Member der Klasse klassifiziert; was soll da noch irgendeine künstliche Benennung? Ich schreibe ja auch nicht "Auto::autoReifen" oder "Auto::memberAutoReifen". Wo würde man da denn auch hin kommen!? (Auto::memberAutoReifen::membersMemberAutoReifenProfil::membersMembersMemberAutoReifenProfilTiefe [...])

Eure Namenkonventionen erinnern mich, wenn auch nicht so restriktiv, doch sehr an einen Abklatsch der Ungarischen Notation!

Was this betrifft: Wer's meint zu brauchen, der benutzt es halt, und wer nicht, halt nicht. Vorteilhaft ist es nur bei globalen Variablen oder zum eindeutigen ansprechen von überlagernden Variablen ... anderswo würde ich es aber auch nicht anwenden.

[akari]

Hallo

Rexy schrieb:

Klassenmember mit einem Prefix zu vershen halte ich für krank:

Rexy schrieb:

Was this betrifft: Wer's meint zu brauchen, der benutzt es halt, und wer nicht, halt nicht. Vorteilhaft ist es nur bei globalen Variablen oder zum eindeutigen ansprechen von überlagernden Variablen ...

Schon mal dran gedacht, das das Kennzeichnen von Member-Variablen mit zum Beispiel m_ dazu dienen könnte, genau diese Überlagerungen zu vermeiden?

bis bald
akari

[Reyx]

Nein, weil sie in einer gesunden Umgebung mit sauberem Code erst gar nicht entsteht (deshalb sagte ich ja auch "wer's braucht).

Sonst müsste ich sämtliche Variablen die ich jemals in einem Projekt schreibe, mit einem eindeutigen Präfix versehen, da ich ansonsten Namenkonfilte mit irgendeiner externen Bibliothek o.ä. befürchten müsste.

Prinzipiell hast du Recht, aber da stimmt imho das Preis/Leistung-Verhältniss vorne und hinten nicht!

[akari]

Hallo

Sonst müsste ich sämtliche Variablen die ich jemals in einem Projekt schreibe, mit einem eindeutigen Präfix versehen, da ich ansonsten Namenkonfilte mit irgendeiner externen Bibliothek o.ä. befürchten müsste.

Ich habe von Member-Variablen gesprochen... die können mit irgendwelchen externen anderen Sachen gar keine Konflikte hervorrufen, da sie ja im "Namespace" ihrer Klasse liegen.
Oder hab ich dich falsch verstanden?

bis bald
akari

[Reyx]

Nein, aber durch deine eigene Aussage, eben dadurch dass solche Konflikte nicht entstehen können, ist die Notwendigkeit eines Member-Prefixes wiederlegt

Und wenn ich auf Teufel komm raus mal die Parameter in einer Funktion gleich den Membern der Klasse benenne, dann habe ich halt mal einen der wenigen Fälle, wo this seine gute Berechtigung hat!

[jemand ...]

Schon mal dran gedacht, das das Kennzeichnen von Member-Variablen mit zum Beispiel m_ dazu dienen könnte, genau diese Überlagerungen zu vermeiden?

Schon mal dran gedacht, das das Kennzeichnen von Member-Variablen mit zum Beispiel this-> dienen könnte, genau diese Überlagerungen zu vermeiden, nur mit dem Unterschied, dass es ein eingebautes Kennzeichen ist, also z.B: der Compiler das auch überprüft?

Ich will ehrlich gesagt nicht nur am Typnamen wissen, womit ich arbeite, sondern auch am Instanznamen, also z.B: CPersonFactory cGivenPersonFactory, an den Namen der Methoden für Getter, Setter, etc.. (man denke dabei nur an Verkettung von Aufrufen ..). Besonders lustig wird immer das simple umbenennen, denn ich kenn keine IDE, die sowas mit Refactoring schafft und nachdem man selbst zu faul für sowas ist, spießen sich irgendwann mal die Namen.

[rapso]

Reyx schrieb:

Dieses ewige Gepräfixe kann ich nicht nachvollziehen
...Vorteilhaft ist es nur bei globalen Variablen oder zum eindeutigen ansprechen von überlagernden Variablen

Reyx schrieb:

Pointer, Referenz oder was auch immer ist mir dabei ziemlich egal

FileResource..Data();
FileResource..Release();

ich wüste auf anhieb nicht ob das ein pointer oder eine reference ist, bzw -> oder .

Reyx schrieb:

"C" für Klassen halte ich für idiotisch

es ist ebenfalls idiotisch andere vorlieben als idiotisch zu bezeichnen.

Reyx schrieb:

denn wenn ich die Klasse schon benutze, dann weiß ich auch, dass es eine ist.

es ist auch für den moment, bei denen man nicht weiß was es ist.

//ein ctor
CMyBla(..ImageDescriptor* pImgDsc)...

ist ImageDescriptor eine klasse oder eine struct?

mit einem enum zu tun habe -> Wozu also ein Prefix?

wäre

NULLPOINTER

ein enum, const irgendwas oder ein #define

Auch Namespaces sollten mir bekannt sein, wenn ich damit umgehe, bzw. macht es mir jede moderne IDE auch relativ einfach zu erkennen, ob ich mit 'ner variable vom Typ void* agiere oder doch nur einen Namespace unter einem bestimmten Namen erreiche.

klar kann man sich mit tausenden helferlein jede ordnung ersparen, man könnte kennzeichen auch nur durchnummerieren ohne jeglichen zusammenhang zur vergabestelle, trotzdem gibt es eine für menschen ohne hilfsmittel lesbare bezeichnungen, die dir unabhängig von den verwendeten tools aufschluss geben.

Klassenmember mit einem Prefix zu vershen halte ich für krank: Dadurch, dass sie einer Klasse untergeordnet werden, sind sie bereits eindeutig als Member der Klasse klassifiziert; was soll da noch irgendeine künstliche Benennung?
...
...Vorteilhaft ist es nur bei globalen Variablen oder zum eindeutigen ansprechen von überlagernden Variablen

//ctor
CFoo(unsigned int Size):
m_Size(Size)
{
}

Ich schreibe ja auch nicht "Auto::autoReifen" oder "Auto::memberAutoReifen". Wo würde man da denn auch hin kommen!? (Auto::memberAutoReifen::membersMemberAutoReifenProfil::membersMembersMemberAutoReifenProfilTiefe::membersMembersMembersMemberAutoReifenProfilTiefeSet(5))

klar, echte helden können ohne namespaces und namenskonventionen auskommen, wozu denn auch?

[Blue-Tiger]

rapso schrieb:

Reyx schrieb:

Dieses ewige Gepräfixe kann ich nicht nachvollziehen
...Vorteilhaft ist es nur bei globalen Variablen oder zum eindeutigen ansprechen von überlagernden Variablen

Reyx schrieb:

Pointer, Referenz oder was auch immer ist mir dabei ziemlich egal

FileResource..Data();
FileResource..Release();

ich wüste auf anhieb nicht ob das ein pointer oder eine reference ist, bzw -> oder .

Sowas darf man schreiben?
Warum interessiert es dich, ob eine Variable eine Referenz ist oder "a real thing"?

es ist auch für den moment, bei denen man nicht weiß was es ist.

//ein ctor
CMyBla(..ImageDescriptor* pImgDsc)...

ist ImageDescriptor eine klasse oder eine struct?

Ebenfalls: wieso ist's wichtig ob ImageDescriptor eine Klasse oder ein Struct ist?

mit einem enum zu tun habe -> Wozu also ein Prefix?

wäre

NULLPOINTER

ein enum, const irgendwas oder ein #define

Und zum 3ten: ob const oder enum, wann ist der Unterschied wichtig? (Dass man define's rauskennen moecht seh ich evtl. noch ein, dahinter kann sich ja alles moegliche verstecken).

Das soll jetzt bitte nicht als Kritik rueberkommen, ich wuerd wirklich gern wissen, warum diese Unterscheidungen fuer dich/deine Firma wichtig sind?

[otze]

rapso schrieb:

Klassenmember mit einem Prefix zu vershen halte ich für krank: Dadurch, dass sie einer Klasse untergeordnet werden, sind sie bereits eindeutig als Member der Klasse klassifiziert; was soll da noch irgendeine künstliche Benennung?
...
...Vorteilhaft ist es nur bei globalen Variablen oder zum eindeutigen ansprechen von überlagernden Variablen

//ctor
CFoo(unsigned int Size):
m_Size(Size)
{
}

//ctor
Foo(unsigned int size):
size(size)
{
}

und wo soll daran ein Problem sein?

[THX 1138]

warum nicht gleich so?

//ctor
Foo(unsigned int size_):
size(size_)
{
}

Den Paramter braucht man ja weniger oft als die Membervariable.

[Reyx]

rapso schrieb:

FileResource..Data();
FileResource..Release();

ich wüste auf anhieb nicht ob das ein pointer oder eine reference ist, bzw -> oder .

Es ergibt sich aus den Zusammenhang (den ein reales Projekt im Gegensatz zu so einem eingestreuten Code-Snippet haben sollte); falls nicht, sollte man in Erwägung ziehen, sein Design etwas zu überdenken. Andererseits: Womit arbeitet ihr? Vim? Solch ein Codekonstrukt kommt nicht wirklich häufig vor, und falls doch, wird einem jede moderne IDE sehr schnell helfen, herauszufinden, woran man ist.

rapso schrieb:

Reyx schrieb:

"C" für Klassen halte ich für idiotisch

es ist ebenfalls idiotisch andere vorlieben als idiotisch zu bezeichnen.

Idiotisch ist es tatsächlich, andere Vorlieben als idiotisch zu bezeichnen; daher habe ich auch wohl überlegt die Phrase "halte ich" hinzugefügt, um meine persönliche, unverbindliche Meinung darzustellen! Ich habe da keine Kritik an irgendwelchen Vorlieben genommen, sondern lediglich die Methode verurteilt! Was du daraus machst, ist dein Ding!

rapso schrieb:

Reyx schrieb:

denn wenn ich die Klasse schon benutze, dann weiß ich auch, dass es eine ist.

es ist auch für den moment, bei denen man nicht weiß was es ist.

Auch ein Unding, welches mit einer guten IDE Geschichte ist.

rapso schrieb:

wäre

NULLPOINTER

ein enum, const irgendwas oder ein #define

Auch ein Unding, welches mit einer guten IDE Geschichte ist.

klar kann man sich mit tausenden helferlein jede ordnung ersparen, man könnte kennzeichen auch nur durchnummerieren ohne jeglichen zusammenhang zur vergabestelle, trotzdem gibt es eine für menschen ohne hilfsmittel lesbare bezeichnungen, die dir unabhängig von den verwendeten tools aufschluss geben.

Ordnung ist subjektiv, was du machst, mag für dich in Ordnung sein, meiner Meinung nach ist es das schon lange nicht mehr. Künstliches verunstalten der Namen, gezieltes Aushebeln der Refactoring-Möglichkeiten und letzlich doch nicht bessere Software. In einer guten Umgebung mit guter Struktur und einem guten Programmierer entstehen all die Dinge, denen ihr mit euren Namenkonventionen entgegenwirken wollt, erst gar nicht! So zumindest meine Meinung.

rapso schrieb:

Reyx schrieb:

Ich schreibe ja auch nicht "Auto::autoReifen" oder "Auto::memberAutoReifen". Wo würde man da denn auch hin kommen!? (Auto::memberAutoReifen::membersMemberAutoReifenProfil::membersMembersMemberAutoReifenProfilTiefe::membersMembersMembersMemberAutoReifenProfilTiefeSet(5))

klar, echte helden können ohne namespaces und namenskonventionen auskommen, wozu denn auch?

Keine Stellungname zu meinem Post, keine plausible Erklärung, keine erkennbaren Bezugspunkte; sorry, dass kann ich nicht verarbeiten.

Dass ist Namenskonventionen für sinvoll halte, sollte bereits aus meinem ersten Post im Thread hier ersichtlich sein, nur die Art, wie manche Leute das Differenzieren, gibt mir zu Denken übrig.

[rapso]

Blue-Tiger schrieb:

Sowas darf man schreiben?
Warum interessiert es dich, ob eine Variable eine Referenz ist oder "a real thing"?

nein, die .. sind platzhalter, vielleicht ein wenig confusing von mir, pardón.
man möchte vielleicht wissen was für ein typ das ist, um zu wissen welche folgen operationen darauf haben
angenommen es ist ein lokales objekt, dann kannst du ohne probleme "Release" aufrufen damit es seine daten freigibt (macht es vielleicht im destructor auch, aber vielleicht brauchst du den speicher oder möchtest nen port, datei oder eine sonstige resource freigeben). wenn es eine reference ist, dürftest du das objekt nicht releasen, wenn du nicht vorher nachschaust wo es noch benötigt wird. falls es ein lokales objekt ist, kannst du es natürlich releasen wenn du im scope davon sicher bist, dass es nicht benötzigt wird. NATÜRLICH kannst du hinscrollen wo es erzeugt wird, oder mit dem cursor in einer IDE über jedes objekt gehen und dir den typen anzeigen lassen. aber rFileResource sagt dir das auf anhiebt. usw.

es ist auch für den moment, bei denen man nicht weiß was es ist.

//ein ctor
CMyBla(..ImageDescriptor* pImgDsc)...

ist ImageDescriptor eine klasse oder eine struct?

Ebenfalls: wieso ist's wichtig ob ImageDescriptor eine Klasse oder ein Struct ist?

in c++ dürfte das eigentlich komplett egal sein und man könnte grundsätzlich nur noch mit structs arbeiten. aber der sauberkeit wegen arbeitet man mit klassen anders als mit structs. bei structs baut man keine funktionen ein und arbeitet dann auch direkt auf den daten, das würde man bei classen genau andersrum machen. wenn du nun ne struct übergeben bekommst und möchtest auf etwas zugreifen, dann greifst du halt direkt darauf zu. bei klassen würdest du erstmal eine accessor-function implementieren und über die zugreifen, falls sie noch nicht da ist.

mit einem enum zu tun habe -> Wozu also ein Prefix?

wäre

NULLPOINTER

ein enum, const irgendwas oder ein #define

Und zum 3ten: ob const oder enum, wann ist der Unterschied wichtig? (Dass man define's rauskennen moecht seh ich evtl. noch ein, dahinter kann sich ja alles moegliche verstecken).

klar, deswegen sollte man #define für sowas auch nicht mehr nutzen ;), da weiß man nie, was für nen mißt man mitschleppt.
aber zum beispiel

//datei rausschreiben, einen nullpointer in die datei...
File.write(&NULLPOINTER,sizeof(NULLPOINTER));

versuch das mit nem enum und versuch das mit nem const unsigned int
enum hat halt keine speicherposition, es ist nur ein wert, eine konstante hat einen speicherplatz (es gibt je nach compiler und OS auch manchmal die möglichkeit konstanten nachträglich zu modifizieren).

Das soll jetzt bitte nicht als Kritik rueberkommen, ich wuerd wirklich gern wissen, warum diese Unterscheidungen fuer dich/deine Firma wichtig sind?

wie ich schon in meinem ersten posting sagte, styleguides sind wichtig für die zusammenarbeit von menschen. wo jemand "sieht man doch sofort" sagt, kann ein anderer nichts sehen, weil er mit dem source nicht vertraut ist. kann sein dass ein kolege im urlaub ist und man einen bug in seinem source fixen muss, wenn alle die selbe styleguid anwenden, ließt man sich schneller ein. man weiß dann auch eher wo der fehler zu suchen ist und auch sofort, was sich hinter einer variable verbirgt.

pData//könnte einen pointer haben der auf nicht freigegebene daten zeigt
apData//autopointer, wird sich also selbst um die daten kümmern

@otze, ok war ein blödes beispiel, nimm

void CFoo::Init(int Size)
{
   m_Size=Size;
}

[otze]

rapso schrieb:

@otze, ok war ein blödes beispiel, nimm

void CFoo::Init(int Size)
{
   m_Size=Size;
}

void Foo::init(int size)
{
   this->size=size;
}

einzige stelle bei der ich bei meiner naming convention this-> benutze

@1310-Logic

wieso haste meinen code verkompliziert?