Konventionen

[DrGreenthumb]

Optimizer schrieb:

Wenn man nicht für einen Typ und einer Instanz auf zwei verschiedene Namen kommt, zeigt mir das, dass derjenige diese beiden Begriffe offenbar nicht so gut auseinander halten kann.

so ein Blödsinn.

void insert(car car);

Wieso sollte die Klasse anders heißen, als die Instanz?

void insert(car herbie);

??

Das macht keinen Sinn.

Ich finde es nach wie vor einfacher, wenn ich im Code einfach alles klein schreiben kann.

[Bashar]

manche schreiben theCar oder aCar, bei Membern itsCar etc. Gar nicht so schlecht, auch wenn ich das nicht machen würde.

[***]

@DrGreenthumb: Tja, da fehlt C++ eben ein Schlüsselwort. 'auto' etc. schafft Ersatz, um zu verdeutlichen, dass es sich um eine Deklaration handelt.

Das ist doch wohl nicht dein Ernst? Das blöde völlig überflüssige typename in:

for(typename vector<vector<T> >::iterator i=nums.begin();i!=nums.end();++i)

,das ausser mir mehr Tipparbeit, weniger Lesbarkeit und von keinem Compiler gebraucht wird, willst du also überall einführen?

Und nur mal so ne Frage was zum Geier noch mal ist denn an:

Foo foo;

schlecht? oder an:

BigCar big_car;

100% lesbar und Verwechlungen, für Programmierer und Compiler, komplete ausgeschlossen.

int main(void)
{
     auto Tilt Tilt;
     return 0;
}

Wenn wir nun:

Foo Foo;

schreiben dann überlass ich dir den N00bs zu erklären, dass:

Foo++::value_type value_type;

genauso falsch ist wie:

Foo::value_type Foo::value_type;

Und jetzt mal ganz davon abgesehen, dass ein einfaches edit > find jetzt nicht mehr ausreicht um nach Instancen oder Typen zu suchen.

Wenn man nicht für einen Typ und einer Instanz auf zwei verschiedene Namen kommt, zeigt mir das, dass derjenige diese beiden Begriffe offenbar nicht so gut auseinander halten kann.

so ein Blödsinn.

Da sieht man es ja, ein Auto ist eben nicht mein Auto. Also heist das:

void insert(car my_car);

[Gast]

DrGreenthumb schrieb:

Optimizer schrieb:

Wenn man nicht für einen Typ und einer Instanz auf zwei verschiedene Namen kommt, zeigt mir das, dass derjenige diese beiden Begriffe offenbar nicht so gut auseinander halten kann.

so ein Blödsinn.

void insert(car car);

Wieso sollte die Klasse anders heißen, als die Instanz?

void insert(car herbie);

??

Das macht keinen Sinn.

Ich finde es nach wie vor einfacher, wenn ich im Code einfach alles klein schreiben kann.

Klassenname == Typbezeichnung. WAS ist es?
Instanzname == Aufgabenerklärung. WOFÜR ist es da?

Das sind für mich zwei verschiedene Dinge. Kannst du ja anders sehen.

[Bashar]

Optimizer schrieb:

Klassenname == Typbezeichnung. WAS ist es?
Instanzname == Aufgabenerklärung. WOFÜR ist es da?

Du meinst vielleicht Rollenbezeichnung? Wenn es passt, warum nicht ... string name, double amount ... aber manchmal hat man eben nur generische Rollen. Entweder weil der Kontext sehr allgemein ist, oder weil die Klasse auf eine bis sehr wenige Rollen eingeschränkt ist.

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