Thema: "Naming Conventions" (mein Tip!)

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

[rapso]

Reyx schrieb:

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.

wenn man sich einen fremden/alten source anschaut, hat man nicht sofort überblick über das ganze projekt. dafür sind styleguids da, damit man sich nicht durch verschiedene sourcestücke hangeln muss um eine Var deuten zu können. wenn jemand nur für sich codet, weiß er wahrscheinlich woran er bei den benennungen ist.

Reyx schrieb:

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!

ändert leider nichts daran, dass du die vorlieben der anderen als idiotisch betitelst.

Reyx schrieb:

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.

und mit einer guten styleguid nie vorhanden ist/war.

Reyx schrieb:

rapso schrieb:

wäre

NULLPOINTER

ein enum, const irgendwas oder ein #define

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

und ebenfals mit einer guten styleguid nie in frage stünde.

Reyx schrieb:

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.

ja, da stimm ich dir zu, ein einzelner programmierer an einem projekt kann arbeiten wie er will und ob mit oder ohne styleguid wird wohl fast dasselbe rauskommen(nein, das ist keine ironie, da stimm ich dir ehrlich zu, ich selbst hatte auch keine styleguide bevor ich in einer firma arbeitete und kamm auch nie auf den gedanken ich hätte sowas gebraucht). in einer umgebung mit 50programmierern kann man jedoch nicht erwarten, dass alle ein überblick über das ganze projekt und jedes detail davon haben. menschen sind nunmal so gemacht, dass sie daten besser verarbeiten, wenn sie ihnen besser presentiert werden. dafür sind dann styleguids, und auch um trivialfehler auszuschliessen. einige c++ konstrukte wie const oder explicit könnte man theoretisch auch sein lassen und davon ausgehen dass jeder weiß worum es dabei geht, aber diese nur zum vermeiden menschlicher fehler existierenden dinge sind schon in dem standard. und darauf zielt unsere styleguide auch ab,sie schreibt z.b. vor, dass vergleichsoperationen die constanten linksstehend haben (entnommen aus einer IBM styleguid bei der ein if(blabla=true)... einen folgeschweren/kostenintenstiven fehler verursachte).

Reyx schrieb:

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.

sollte eine anspielung darauf sein, dass es leute gibt, die absolut keine namespaces nutzen wollen oder alles nur in ihrem namesspace schreiben. klar geht auch, unsere styleguid schreibt da was anderes vor, aber ein programm läuft ohne namespaces genau so gut und ein programmierer kann seinen source überblicken ohne dass er ihn in namespaces eintaucht... für anderer wären namespaces aber hilfreich.

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.

wir haben bei uns in der firma auch einige dinge aus der styleguid rausgenommen, z.b. float fValue; unsigned int uiCount; weil diese prefixe unnötig sind, spätestens wenn ein warning vom compiler rauskommt, weiß man dass man falsch lag :).
gut finde ich hingegen, dass man sich auf Size für bytegrößen und Count für festlegt, sonst gab es manchmal klassen in denen Size(),Count() und Number() den selben wert zurücklieferte, weil jeder für "seinen" code was anderes annahm, bzw gesucht hatte. das zeigt nur, dass jeder sicherlich einen guten code schreiben könnte, aber gemeinsamm braucht man eben solche protokolle zur zusammenarbeit.

[rapso]

otze schrieb:

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

klar ist ne möglichkeit, die lösung an sich find ich auch ok. ich bin aber gegen dieses this->, weil es n00bs, die sich mal mit so nem code auseinander setzen auf die idee bringt, man sollte immer this-> für member verwenden und daraus entsteht dann ein recht grausiger code. ich frage mich aber wie du dann accessorfunktionen schreibst, sowas wie:

class CFoo
{
void* data;
...

public:

    void* data(){return this->data;}
}

dürfte doch nicht compilieren? mir würden da spontan nur set/get funktionen aus c zeiten einfallen
klär mich auf

[rapso]

1310-Logik schrieb:

warum nicht gleich so?

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

Den Paramter braucht man ja weniger oft als die Membervariable.

weil jemand später mal auf die idee kommen könnte, dass man noch parameter dazubaut

print(char* pStr);

..hah, schaut unsicher aus

print(char* pStr,int size);

phu, das schaut nun sicher aus
dabei würde er, falls es ein size gab, size überschreiben und falls das verwendet wurde, wäre die funktion im A...

oder meinst du grundsätzlich _ als postfix für alle parameter?

[volkard]

rapso schrieb:

...

das tut mit weh.

[rapso]

volkard schrieb:

rapso schrieb:

...

das tut mit weh.

du tust mit auch öfter weh.

[volkard]

1310-Logik schrieb:

warum nicht gleich so?

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

Den Paramter braucht man ja weniger oft als die Membervariable.

das mach ich seit jahren so. den bedarf dafür gibts übrigend *nur* nur bei konstruktoren, also ausreichend selten.

[otze]

rapso schrieb:

klar ist ne möglichkeit, die lösung an sich find ich auch ok. ich bin aber gegen dieses this->, weil es n00bs, die sich mal mit so nem code auseinander setzen auf die idee bringt, man sollte immer this-> für member verwenden und daraus entsteht dann ein recht grausiger code.

dann muss man diesen n00bs erklären, dass man this-> nur in ganz wenigen spezialfällen benutzt, und auch nur wnen man weis, was man tut!

ich frage mich aber wie du dann accessorfunktionen schreibst, sowas wie:

class CFoo
{
void* data;
...

public:

    void* data(){return this->data;}
}

dürfte doch nicht compilieren? mir würden da spontan nur set/get funktionen aus c zeiten einfallen
klär mich auf

ich benutze eigentlich auch noch die guten alten set/get funktionen
sie sagen genug aus, und man kann wenig mit falsch machen. Im moment überleg ich mir aber, davon weg zu gehen und properties zu nutzen.

[rüdiger]

@rapso
Eure Namenskonventionen sehen mir eher danach aus, als wollte man eher die Fehler eines uneinheitlichen Programmierstil reduzieren wollen.

Ich benutze eigentlich sehr wenige POD-structs. Die die ich benutze sind in der Regel ziemlich lokal angesiedelt oder es ist eindeutig zu verstehen das es sich um simple Datensammlungen handelt. Daher würde ich bei einem ImageDescriptor kein zweites mal nachdenken und sofort von einer Klasse ausgehen. Aber selbst wenn das alles nicht der Fall ist, so verrät mir ein CImageDescriptor oder ein SImageDescriptor immer noch nicht wie ich die Klasse oder POD-struct benutze.

Oder kannst du mir nun sagen, wie erzeuge ich ein CImageDescriptor oder ein SImageDescriptor? Da ist man eh auf die Dokumentation, ein Blick in den Code oder die IDE angewiesen. Warum benötige ich dann also ein extra C oder S?

Bei den Konstanten seh ich das ähnlich, im Zweifelsfall müsste ich ja erst nachgucken, weil ich nicht weiß ob EVENTS_N nun ein enum oder ein int const ist und so also eEVENTS_N oder cEVENTS_N heißt. Da sehe ich keinen großen Mehrwert. Ich würde eher sagen nur const benutzen (#define sollte man ja eh nicht benutzen) oä.

[rapso]

otze schrieb:

dann muss man diesen n00bs erklären, dass man this-> nur in ganz wenigen spezialfällen benutzt, und auch nur wnen man weis, was man tut!

klingt als hättest du das noch nie machen müssen, ich hab das am WE stunden dazu verbracht...

otze schrieb:

ich benutze eigentlich auch noch die guten alten set/get funktionen
sie sagen genug aus, und man kann wenig mit falsch machen. Im moment überleg ich mir aber, davon weg zu gehen und properties zu nutzen.

meinst damit c#?

im prinzip tauscht du m_ gegen get/set, ich würde das nicht als besser ansehen;)

[rapso]

kingruedi schrieb:

@rapso
Eure Namenskonventionen sehen mir eher danach aus, als wollte man eher die Fehler eines uneinheitlichen Programmierstil reduzieren wollen.

eher als was?
ich denke genau dazu ist unsere styleguide da, sicherlich nicht dazu um programmierer zu unnötigen dingen zu nötigen. deswegen haben wir auch einige dinge rausgenommen gehabt. die styleguide wurde auch gefreezt und auch wenn sie nicht perfekt ist, werden keine ewiglangen diskussionen mehr geführt, sondern man hällt sich daran damit code konstant lesbar bleibt.

Ich benutze eigentlich sehr wenige POD-structs. Die die ich benutze sind in der Regel ziemlich lokal angesiedelt oder es ist eindeutig zu verstehen das es sich um simple Datensammlungen handelt. Daher würde ich bei einem ImageDescriptor kein zweites mal nachdenken und sofort von einer Klasse ausgehen.

ich nutze structs auch sehr selten, eigentlich fast nur für gemappte resourcen und als initialisierungskonstrukte für factories... aber wie du schon sagst, würdest du darüber nachdenken was ImageDescriptor ist, bei 50leuten die nachdenken, kann es passieren, dass einer was anderes denkt, das ist menschlich.

Aber selbst wenn das alles nicht der Fall ist, so verrät mir ein CImageDescriptor oder ein SImageDescriptor immer noch nicht wie ich die Klasse oder POD-struct benutze.

nein, die benutzung wird dadurch nicht geklärt, da kommt man über gedocte interfaces/header nicht hinweg. aber wenn du einen source liest, weißt du eher was das zu bedeuten hat. aber auf der anderen seite, wenn du im source

apData

siehst, weißt du dass die resource freigegeben wird, bei pData könntest du ein memoryleak oder sogar ne accessviolation bedenken müssen, wenn du das nutzt. einen änlichen unterschied hast du ja bei param-by-reference und param-by-pointer auch. eine funktion die einen pointer annimt MUSS es handlen können dass es ein NullPointer sein kann den sie bekommt. eine die eine reference will, da mußt du dich drum kümmern, dass du sie sauber fütterst. fütterst du eine die einen pointer erwartet, darfst du sie nicht mit "new CFoo" füttern, eine mit nem autopointer/smartpointer/refcountpointer (je nach festlegung) kümmert sich selber um die daten auf die der pointer zeigt.

Oder kannst du mir nun sagen, wie erzeuge ich ein CImageDescriptor oder ein SImageDescriptor? Da ist man eh auf die Dokumentation, ein Blick in den Code oder die IDE angewiesen. Warum benötige ich dann also ein extra C oder S?

ich kann dir sagen, dass du einen SImageDescriptor so erzeugst:
SImageDescriptor Desc;
ich kann dir sagen, dass du ein CImageDescriptor vermutlich über einen konstruktor erzeugst der eventuell parameter braucht (SImageD... hat keine funktionen und ctors)
ich kann dir sagen, dass du ein IImageDescriptor nicht erzeugen könntest, sondern von einer factory erzeugen müßtest, auch deleten könntest du es nicht selbst und müßtest das über die factory machen (oder es gibt ein refcounting, dann würdest du aber einen CAPImadeDescriptor nutzen, der sich um alles kümmert.

das weiß ich alles nur aufgrund des namens ohne dass es die objekt-deklaration überhaupt gibt

Bei den Konstanten seh ich das ähnlich, im Zweifelsfall müsste ich ja erst nachgucken, weil ich nicht weiß ob EVENTS_N nun ein enum oder ein int const ist und so also eEVENTS_N oder cEVENTS_N heißt. Da sehe ich keinen großen Mehrwert. Ich würde eher sagen nur const benutzen (#define sollte man ja eh nicht benutzen) oä.

du würdest EVENTS_N kennen ohne das prefix zu sehen? naja, aber wie ich schon sagte ist es für die lesbarkeit des codes und dann auch die richtige nutzung davon. es hilft dir natürlich nichts, wenn du etwas suchst. dann mußt du nachsehen ob es ESIGNAL oder EEVENT oder EVENT oder ... gibt.

[unkreativ``]

rapso schrieb:

und mit einer guten styleguid nie vorhanden ist/war.
...
und ebenfals mit einer guten styleguid nie in frage stünde.

Deiner Meinung nach ist also jede weitere Innovation, Weiterentwicklung völlig unnötig, weil Namenskonventionen bereits die perfekte Lösung sind?

Ihr (sämtliche Befürworter von Konventionen mit Präfixen) zählt doch immer nur Argumente auf warum Namenskonventionen besser als gar nichts sind, mich würden aber Vorteile gegenüber heutzutage üblichen IDEs interessieren ..

[rapso]

unkreativ`` schrieb:

rapso schrieb:

und mit einer guten styleguid nie vorhanden ist/war.
...
und ebenfals mit einer guten styleguid nie in frage stünde.

Deiner Meinung nach ist also jede weitere Innovation, Weiterentwicklung völlig unnötig, weil Namenskonventionen bereits die perfekte Lösung sind?

da intepretierst du viel zu viel rein, als ich gesagt habe. natürlich ist eine gute IDE wichtig, ich könnte ohne mein VisualAssist garnicht mehr leben ;).

ich könnte nun aber fragen, glaubst du man sollte gute dinge sein lassen, weil es auf mit ein wenig mehr aufwand auch auf andere weisen ginge?

[THX 1138]

rapso schrieb:

1310-Logik schrieb:

warum nicht gleich so?

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

Den Paramter braucht man ja weniger oft als die Membervariable.

weil jemand später mal auf die idee kommen könnte, dass man noch parameter dazubaut

das geht doch dann auch ohne aufwand:

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

oder meinst du grundsätzlich _ als postfix für alle parameter?

Nein nur für Members, denn die Übergabeparameter für Members brauch ich nur in den Konstruktoren und Accessoren, die Membervariable auch in x anderen Methoden der Klasse. Da spar ich mir die Prä/Postfixe dann.