Welches Prä- oder Suffix nutzt ihr für Memberattribute?

hustbaer schrieb:

Ja, my. *würg*

Och, nö. Zu bunny_cookie passt m_ sehr gut, aber wie sähe m_BunnyCookie aus? Dann auf jeden Fall myBunnyCookie .

Nexus

Schön, dass wir uns so einig sind

An diejenigen, die irgendein Prä- oder Postfix zur Kennzeichnung von Membervariablen verwenden: Benutzt ihr auch eins für statische Variablen?

hustbaer

BunnyCookie schrieb:

hustbaer schrieb:

Ja, my. *würg*

Och, nö. Zu bunny_cookie passt m_ sehr gut, aber wie sähe m_BunnyCookie aus? Dann auf jeden Fall myBunnyCookie .

Keine dieser Varianten, sondern m_bunnyCookie .

hustbaer

Nexus schrieb:

An diejenigen, die irgendein Prä- oder Postfix zur Kennzeichnung von Membervariablen verwenden: Benutzt ihr auch eins für statische Variablen?

static in Klassen = s_theVar
static const in Klassen = TheConst
auf Namespace Scope (egal ob static oder extern) = g_theVar
const auf Namespace Scope (egal ob static oder extern) = TheConst

Dravere schrieb:

volkard schrieb:

Tja, ist bei mir kein Problem. Setter habe ich noch viel seltener. Ich schreibe mehr goto als Setter.

Shade Of Mine schrieb:

(falls man sowas denn mal brauchen sollte - was, wie volkard ja schon gesagt hat, nur sehr selten der Fall ist):

Könntet ihr das bitte präzisieren, würde mich wunder nehmen. Schreibt ihr Model Klassen ohne Setter? Muss man immer neue Objekte erstellen, wenn man eine Variable anpassen möchte? Ich habe so meine liebe Mühe zu glauben, dass ihr "selten" Setter verwendet.

Das wird wohl auch programmabhängig sein. Wenn ich im Programm bei einem Objekt später etwas setzen kann, wird man wohl auch meistens einen setter nehmen. Wenn ich die Koordinaten für ein Objekt eingeben kann, würde ich auch sowas wie object.setX... machen. Man könnte es auch object.moveToX... nennen, was aber immer noch ein setter bleibt.

wxSkip

Ich nehme auch keinen Präfix/Suffix für Membervariablen. Bei Settern/Gettern oder Konstruktoren nehme ich dann häufig p_ als Präfix für die Parameter. Die Funktionen heißen dann GetMember() / SetMember()

this-*gt*that

Shade Of Mine schrieb:

this->that schrieb:
Ich benutze nur ein "m". Ist unauffällig, hilft mir mich daran zu erinnern dass das ein Member ist und löst auch das Ctor Parameter Problem:
Foo(int bar) : mBar(bar) { }
Meine Ctors sehen so aus:
Foo(int bar) : bar(bar) {}
Wo genau siehst du hier ein Problem?

Sollten da nicht beide bar das selbe ansprechen?

Dravere

this->that schrieb:

Sollten da nicht beide bar das selbe ansprechen?

Nein.

Siehe dazu im Standard 14882:2003 Kapitel 12.6.2 Initializing bases and members:

Abschnitt 2 schrieb:

Names in a mem-initializer-id are looked up in the scope of the constructor’s class...

Abschnitt 7 schrieb:

Names in the expression-list of a mem-initializer are evaluated in the scope of the constructor for which the mem-initializer is specified.

Es wird nach Abschnitt 7 gleich ein Beispiel dafür gegeben, dass dies auch wirklich funktioniert:

class X {
  int a;
  int b;
  int i;
  int j;
public:
  const int& r;
  X(int i): r(a), b(i), i(i), j(this->i) {}
};

initializes X::r to refer to X::a, initializes X::b with the value of the constructor parameter i, initializes X::i with the value of the constructor parameter i, and initializes X::j with the value of X::i; this takes place each time an object of class X is created.] [Note: because the mem-initializer are evaluated in the scope of the constructor, the this pointer can be used in the expression-list of a mem-initializer to refer to the object being initialized.

Grüssli

Blue-Tiger

Nexus schrieb:

Eisflamme schrieb:

Okay, gar kein Suffix oder Präfix find ich auch gut.

Finde ich nicht gut. Jedenfalls gefällt mir sowas gar nicht:
void MyClass::SetValue(int newValue)
{
    value = newValue;
}

Warum gefaellt dir das nicht? Ich find das okay so.

Ad Thema: ich verwende auch gar nix. In ganz extremen Ausnahmefaellen bekommen die Parameter des Ctor Postfix-Underscores (z. B. bei structs, die im Wesentlichen nur mehrere Daten sammeln).

asc

Privat nutze ich keine Prä-/Suffixe für Variablen (egal welcher Art), wenn eine Unterscheidung zwischen Parameter und Member nötig ist, setze ich ein "this->" vor die Membervariable.

In der Firma haben wir uns nach zähen Verhandlungen mit unseren Chef dazu durchringen können, wenigstens auf eine unter C++ "üblichere" Schreibweise zu wechseln (m_ statt wie vorher F vor Membervariablen).

volkard

asc schrieb:

(m_ statt wie vorher F vor Membervariablen).

F? lol. War wohl der einzige freie Buchstabe.

audacia

volkard schrieb:

asc schrieb:

(m_ statt wie vorher F vor Membervariablen).

F? lol. War wohl der einzige freie Buchstabe.

F wie Field. Ist in Delphi üblich.

Zum Thema: Man kann drüber streiten, ob ein Präfix sinnvoll ist oder nicht - wichtig ist aber vor allem, daß es einheitlich gehandhabt wird. Und die Einheitlichkeit kommt in C++ ganz fürchterlich zu kurz, man lese nur diesen Thread. Z.B. in Delphi hält sich praktisch jeder an das Object Pascal Style Guide, präfiziert seine Felder mit "F" und seine Typen mit "T" und denkt nicht weiter drüber nach. Lieber einen einheitlich komischen Präfix als zwanzig verschiedene noch so sinnvolle Workarounds

Nexus

audacia schrieb:

Lieber einen einheitlich komischen Präfix als zwanzig verschiedene noch so sinnvolle Workarounds

Ich bin ehrlich gesagt froh, dass mir C++ nicht den Stil vorschreibt. Solange man innerhalb eines Projekts konsistent ist, sehe ich unterschiedliche Namenskonventionen auch nicht als riesiges Problem. In meinem Code erkenne ich z.B. Bezeichner aus der Standardbibliothek und Boost sofort, weil sie Unterstriche verwenden, was ich selbst nur bei Makros tue.

Dravere

Nexus schrieb:

Solange man innerhalb eines Projekts konsistent ist, sehe ich unterschiedliche Namenskonventionen auch nicht als riesiges Problem.

Problem ist aber gerade, dass man nicht konsistent bleiben kann, weil alle Bibliotheken, welche man in C++ verwendet, einen anderen Stil verfolgen. Ich finde es sehr gut, wenn sich alle an den Stil der Standardbibliothek halten.
Finde ich auch so schön in C#, wo sich wirklich so gut wie jeder an den Stil hält. Dadurch kann man jegliche Bibliothek nehmen und es bleibt ein konsistenter Code.
(Dies schliesst übrigens Prä- oder Suffixe bei Membervariablen aus, da diese dem Programmierer, welcher die Bibliothek verwendet, normalerweise verborgen bleiben. Mir geht es hier nur um die Schnittstellen)

In C++ ist wohl das Problem, dass die Standardbibliothek einfach einen zu unpopulären Stil verfolgt.

Grüssli