Konventionen

[Gerard]

hast sich eigentlich der unterstrich am ende vom member variablen durchgesetz oder ist er schon in vergessenheit geraten?

bin nicht mehr so uptodate

[Konrad Rudolph]

Gerard schrieb:

hast sich eigentlich der unterstrich am ende vom member variablen durchgesetz oder ist er schon in vergessenheit geraten?

Unterschiedlich. Ich lese ihn regelmäßig, genauso oft aber den Unterstrich am Anfang und das Präfix 'm_' (das ich selbst inzwischen ebenfalls verwende).

[***]

Gerard schrieb:

hast sich eigentlich der unterstrich am ende vom member variablen durchgesetz oder ist er schon in vergessenheit geraten?

bin nicht mehr so uptodate

Sollte der sich durchsetzen? Da hab ich wohl was verschlaffen, oder war das dieser mit dem IDE Namensvervollständigung begründete Still, der anderseits aber nur schlecht aussieht?

[Gerard]

ahja was ich noch beitragen wollte,
@volkard ich glaube die kleinschreibung in c++ kommt aus unix/linux, aber ob sie in c++ so viel sinn hat?

und sonst habe ich schon mit result_set und resultSet gerarbeitet, meine schlussfolgerung ist: variablen namen sind etwas redseliger wenn ich unterstriche benutze, wo durch der code einiges an qualität gewinnt.
mit resultSet könnte ich noch gut leben, aber damit der still duchgehen gleich ist wird da raus ein result_set

[Gerard]

*** schrieb:

Gerard schrieb:

hast sich eigentlich der unterstrich am ende vom member variablen durchgesetz oder ist er schon in vergessenheit geraten?

bin nicht mehr so uptodate

Sollte der sich durchsetzen? Da hab ich wohl was verschlaffen, oder war das dieser mit dem IDE Namensvervollständigung begründete Still, der anderseits aber nur schlecht aussieht?

naja soweit ich mich erinnern kann was das so:

• m_member ist zu lang
• _member ist problematisch wegen dem unterstrich am anfang weil solche worte reserviert sind (in globalen namespace und mit großbuchstaben, das trift zwar auf member nicht zu aber besser man gewöhnt sich das erst gar nicht dran)
• dann sind die leute auf member_ gekommen,

also ist memeber_ das was sich durchsetzen sollte, (wobei ich mich an eine prognose erinnern kann wonach es nur ein zwischen schritt zu "member" ist)

[Gast]

Ich empfehle, da es ja (aus fadenscheinigen Gründen) so wichtig ist, etwas als Member zu kennzeichnen, das Postfix name_m_priv, wobei m für Member und priv für privat steht. Analog prot für protected und pub für public.

Und damit auch keiner vergisst, von was für einem Typ das Ding ist, kann man das ja noch explizit mit Präfixen kennzeichen. Ich denke da an sowas:

p_char_arr_my_name_m_priv

Jetzt muss man sich nicht mehr mühsam und unverständlich die Definition

private:
    char* my_name

ansehen, sondern sieht auf einen Blick: Aha, ein Pointer auf ein char-Array, Member einer Klasse und privater Zugriffsschutz.

Ich bin richtig begeistert von dieser Idee. Ich werde sie mal zur Standardisierung vorschlagen.

[Konrad Rudolph]

Optimizer schrieb:

Ich bin richtig begeistert von dieser Idee. Ich werde sie mal zur Standardisierung vorschlagen.

LOL. Wieso verwendet man nicht gleich die Typensignatur einer jeden Variable als Postfix? Ich mag eh die "Dekorierung" der exportierten Funktionen im DepWalker.

[operator void]

Wow, wieviel Aufwand man betreiben kann, um alles gleich zu kapitalisieren... Da tippe ich doch lieber ab und zu mal auf die Shift-Taste, so anstrengend ist "Foo foo" auch nicht. Der einzige echte Nachteil ist doch, dass die C++-Standardbibliothek in der Konvention inkompatibel ist. Da ist es mal type, mal type_t und mal type_type *bäh*

Optimizer schrieb:

Ich empfehle, da es ja (aus fadenscheinigen Gründen) so wichtig ist, etwas als Member zu kennzeichnen...

Brauchst ja nicht gleich die Veralberungskeule rausholen, nur weil manche Leute gerne das 'get' vorm Funktionsnamen weglassen.

[volkard]

operator void schrieb:

Brauchst ja nicht gleich die Veralberungskeule rausholen, nur weil manche Leute gerne das 'get' vorm Funktionsnamen weglassen.

doch, das war gut. vielleicht raffts ja so mal einer.

[Irgendwer]

Optimizer schrieb:

Ich empfehle, da es ja (aus fadenscheinigen Gründen) so wichtig ist, etwas als Member zu kennzeichnen, das Postfix name_m_priv, wobei m für Member und priv für privat steht. Analog prot für protected und pub für public.

Und damit auch keiner vergisst, von was für einem Typ das Ding ist, kann man das ja noch explizit mit Präfixen kennzeichen. Ich denke da an sowas:

p_char_arr_my_name_m_priv

Jetzt muss man sich nicht mehr mühsam und unverständlich die Definition

private:
    char* my_name

ansehen, sondern sieht auf einen Blick: Aha, ein Pointer auf ein char-Array, Member einer Klasse und privater Zugriffsschutz.

Ich bin richtig begeistert von dieser Idee. Ich werde sie mal zur Standardisierung vorschlagen.

Du bist ja deutsch gell? Dann haben wir hier Deutsche Notation, vielleicht kauft M$ dir sie ja ab als ersatz für die ungarische .

doch, das war gut. vielleicht raffts ja so mal einer.

Du Optimist, glaubst du wirklich, dass man sich bei Stillfragen je auf irgendetwas einigen wird?

[operator void]

Vielleicht bin ich da die unverschämte Ausnahme, aber mir würde eine eher argumentative Begründung mehr helfen als besagte Keule. Was sprach denn gegen get-Weglassen?
Argument 1) Dass alle Funktionsnamen Tätigkeiten beschreiben müssen. Aber sich das 'get' zu denken finde ich nicht schwer: list.size(), person.firstName(), obj.x()...
Argument 2) Dass man dann auf die Idee kommt, vec.size() = 4 schreiben zu wollen. Das Problem kann ich mir ja vorstellen, auch wenn ich es nicht hatte. Aber wie hilft es da, überall das get wegzulassen? vec.back() = 6 geht ja.
Argument 3) ______________________

[Gast]

In C++ finde ich es schon mal besonders angebracht, get zu schreiben, weil Member nicht genauso heißen dürfen wie Methoden. Das Problem kann man natürlich lösen, indem man seine Member irgendwie komisch benennt.

vec.back() = 6 geht ja.

In dem Sinne sehe ich back() auch nicht als getter, weil es einem vec[vec.size()-1] entspricht. Außer natürlich, man betrachtet operator[] auch als getter. Hängt aber IMHO von der Verwendung ab.

Allerdings sehe ich es mit dem get nicht so eng. Ich persönlich schreibe schon gerne get, weil Methoden sind für mich "tun-Sachen". Deshalb muss da einfach ein Verb hin. Ich finde es aber auch nicht schlimm, wenn es jemand anders hält.
Seltsamerweise heißen die Methoden bei den Collections im Java-API auch einfach size(), obwohl die sich sonst überall an die Konvention halten.

[Gast]

@Irgendwer: Ne, die haben jetzt schon ihre PascalCase Konvention. Und damit sie ja nicht get schreiben müssen, haben sie die Proberties eingeführt.

[__me]

get ist doof

[interpreter]

Sagt euch der Spruch "Aus einer Mücke einen Elefanten machen" etwas?

[volkard]

operator void schrieb:

Vielleicht bin ich da die unverschämte Ausnahme, aber mir würde eine eher argumentative Begründung mehr helfen als besagte Keule. Was sprach denn gegen get-Weglassen?
Argument 1) Dass alle Funktionsnamen Tätigkeiten beschreiben müssen. Aber sich das 'get' zu denken finde ich nicht schwer: list.size(), person.firstName(), obj.x()...
Argument 2) Dass man dann auf die Idee kommt, vec.size() = 4 schreiben zu wollen. Das Problem kann ich mir ja vorstellen, auch wenn ich es nicht hatte. Aber wie hilft es da, überall das get wegzulassen? vec.back() = 6 geht ja.
Argument 3) ______________________

das war bloß ein argument, nicht drei: wenn der funktionsname offensichtlich kein verb ist, denkt man sich eben get oder set dran.
aber was ist bei unoffensichtlichen verben wie .begin(), .start(), .collect()?
.begin ist offesichtlich ein hauptwort, weil die stl hier ien übliches verbrechen begeht und man sich an .begin() gewöhnt hat.
.start() ist ebenso ofensichtlich ein tuwort, weil man anderenfalls ja begin() geschrieben hätte. (ups, bin wieder beim lächerlichmachen, aber das geht so furchbar einfach, weil dein stil systeminharänt lächerlich ist.)
.collect() ist vermutlich ein verb. nicht sehr sicher, weil nubes so .collection() abkürzen.

[volkard]

Irgendwer schrieb:

Du Optimist, glaubst du wirklich, dass man sich bei Stillfragen je auf irgendetwas einigen wird?

nein. ich glaube, daß es immer irgendwelchen aberglauben geben wird. heute sind es unterstiche und uml, morgen werden wir was anderes haben.

[Gast]

(ups, bin wieder beim lächerlichmachen, aber das geht so furchbar einfach, weil dein stil systeminharänt lächerlich ist.)

roflmao!

[operator void]

Optimizer schrieb:

In C++ finde ich es schon mal besonders angebracht, get zu schreiben, weil Member nicht genauso heißen dürfen wie Methoden. Das Problem kann man natürlich lösen, indem man seine Member irgendwie komisch benennt.

Ich verwende Methoden öfter als Member; dann verstümmele ich lieber die privaten Eingeweide, die nur die Klasse selbst sieht. Aber immerhin hört sich dein Beitrag nicht mehr danach an, als gäbe es die Eine Göttliche Wahrheit (tm).

volkard schrieb:

das war bloß ein argument, nicht drei: wenn der funktionsname offensichtlich kein verb ist, denkt man sich eben get oder set dran.
aber was ist bei unoffensichtlichen verben wie .begin(), .start(), .collect()?

Ich habe hier x(), map(), input(), name(), mode(), width(), actions()..., und nur map() und name() könnte man mit viel Fantasie für Verben halten. Naja, immerhin weiß ich jetzt deine Begründung. Drauf achten kann man ja mal

[Plemplem]

operator void schrieb:

map() und name() könnte man mit viel Fantasie für Verben halten

Fantasie braucht man dazu nicht. Habe ich gerade ganz ohne geschafft.

Hab gleich auf anhieb gedacht, das wären Verben. Könnte mir auch was drunter vorstellen. Wenn die doofen Klammern nicht wären(Eigenschaften statt Methoden), hätte ich auch ne Idee, was das sein könnte. Aber sonst... nö.

Ach ja, @Volkard: Auch begin() ist ein Verb. (Für mich.)