Thema: "Naming Conventions" (mein Tip!)

[rapso]

1310-Logik schrieb:

rapso schrieb:

1310-Logik schrieb:

hier brauch ich den _
na ja, den _ hab ich mir generell angewöhnt für temporäre variablen, (zB auch in if abfragen) , anstatt x_temp zu schreiben.
das mit den globals ist schon klar, hab aber im moment noch einen mischcode wegen der SDL, die ich mal grob ausm tutorial übernommmen hab. werd die dann auch noch kapseln, aber erstmal muss ich wissen, wie der hase läuft

ob du nun die localen grundsätzlich makierst, oder die member, am ende hast du die selbe differenzierung, die ich als nützlich ansprach

Genau, nur das ich bei Zugriffen wie rabbit.x nicht mehr tippe als nötig,
während rabbit.m_uix 4 zeichen mehr sind :p

bei:
m_Size = Size;
tippst du
Size = Size_;
ist das der große gewinn den du hast? *hehe*

ich muss m[Shift]S[Tab] = S[Tab] tippen was sollte daran so aufwendig sein?

und wie ich schon sagte, ums tippen geht es nicht, das geht parallel zum denken und bedarf 0 aufwand meinerseits

[rapso]

CStoll schrieb:

...Da ändere ich lieber einmal die Definition "int val;" nach "long val;"...

Ich bin mir über den Typ ja sicher

no offense, aber ich kann dir da nicht ganz folgen... wieso änderst du int zu long wenn du dir über den typen sicher warst, bzw widerspricht sich das nicht?

[CStoll]

Als ich das Programm geschrieben habe, war ich mir noch sicher, daß int reichen sollte (und auch jetzt reicht ein kurzer Blick, um den korrekten Typ festzustellen). Und da ist es mir lieber, überhaupt keine Typkürzel im Namen zu haben als falsche.

[THX 1138]

rapso schrieb:

und wie ich schon sagte, ums tippen geht es nicht, das geht parallel zum denken und bedarf 0 aufwand meinerseits

Nein, es geht um lesbarkeit. Der grosse Gewinn ist, dass ich Size im ersten überflug besser lesen kann, als m_uiSize.

[rapso]

1310-Logik schrieb:

rapso schrieb:

und wie ich schon sagte, ums tippen geht es nicht, das geht parallel zum denken und bedarf 0 aufwand meinerseits

Nein, es geht um lesbarkeit. Der grosse Gewinn ist, dass ich Size im ersten überflug besser lesen kann, als m_uiSize.

um die gegenbehauptung zu stellen: "man" kann besser m_Size lesen.

am ende kommt es nur drauf an was "man" mehr gewohnt ist.

[THX 1138]

drum schrieb ich "ich" kann besser lesen
aber lassen wird das

[groovemaster]

1310-Logik schrieb:

warum nicht gleich so?

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

Den Paramter braucht man ja weniger oft als die Membervariable.

Was aber vollkommen irrelevant ist. Member sind Internas und betreffen den Clienten nicht im geringsten. Leider denken Entwickler zu sehr selbstbezogen, da bist du auch keine Ausnahme. Benutze also entweder keine spezielle Benennung oder _nur_ bei den Membern. Ein Client sollte auf jeden Fall immer

Foo(unsigned int size);

sehen und nicht

Foo(unsigned int size_);

oder was auch immer.
Und der evtl. Mehraufwand beim Schreiben ist schlichtweg zu vernachlässigen.

[THX 1138]

den client interessiert doch eh nur:

Foo(unsigned int xxxx);

weil er eh

foo( any_specific_size );

aufruft.
da ist es doch egal, wie ich die variable intern nenne, oder?

[Jester]

Rufst Du lieber die Funktion

f(int x, int xx, int xxx, int xxxx);
oder die Funktion
f(int x, int y, int width, int height);

auf?

Allerdings gehört der Variablenname nicht zur Funktionsdeklaration. Er kann also im Header und der Implementierung unterschiedlich heißen.

[DEvent]

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.

Du meinst bestimmt, dass man in C++ nur noch mit Klassen arbeiten kann.

In einer OOP-Sprache spielt der Typ eines Objekts überhaupt keine Rolle, bzw der Typ interessiert nicht mehr. Das ist ja einer der Vorteile von OOP.

Es spielt auch keine Rolle ob man mit einem Struct oder Klasse arbeitet. Entweder sind die Attribute Public, dann kann man sie direkt ändern, oder sie sind Privat, dann kann man die Attribute nur über Getter/Setter ändern.
Der einzige Unterschied zwischen Struct und Class ist es, dass in einem Struct die Attribute standard public sind, wärend in Class sie standard privat sind. Ein Struct hat ebenso Contructoren und Methoden.

Es spielt für den Benutzer auch keine Rolle ob ein Attribut Ganzzahl oder Realzahl ist. Entweder er kann dem Attribut eine Realzahl zuweisen oder er kann es nicht.
Einem Attribut/Parameter wie size oder count würde man aber keine Realzahl zuweisen wollen.

[DEvent]

wieso sollten sich IDE und prefixe unbedingt ausschliessen? nur weil man eine IDE hat, muss man doch nicht auf die vorteile einer styleguide verzichten.

Redundanz. Hat sich die Informatik nicht der Verminderung von Redundanz wo es auch nur geht verschrieben?

ich kann jetzt natürlich das argument bringen, dass nicht jede IDE gleich arbeitet und gerade diff-tools oft auf das highlighting von unterschieden spezialisiert sind, nicht auf syntax;)

mit diff-tools Programmierst du ja nicht