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

Michael E.

Bei mir bekommen Parameter einen zusätzlichen Unterstrich, wenn sie lediglich zum Setzen gebraucht werden (was bei mir quasi nur im Konstruktor der Fall ist, Setter habe ich auch sehr wenige). Denn den Parameter brauche ich genau einmal zum Setzen und danach nie wieder. Dann plag ich mich nicht mehr mit den Unterstrichen rum.

class Foo
{
	int bar;

public:
	Foo(int bar_) : bar(bar_)
	{
		// hier arbeite ich mit bar statt bar_
	}

	void setBar(int bar_)
	{
		bar = bar_;
	}
};

volkard

Shade of Mine schrieb:

Keine Ahnung, ich schaue hier gerade durch ein paar Projekte - die setter kann ich an 2 Haenden abzaehlen glaube ich. Diese Zuweisungen finden nahezu immer in den Konstruktoren statt.

Jup, genau wie bei mir. Ich hätte sogar auch mit "Keine Ahnung," angefangen.

Michael E. schrieb:

Bei mir bekommen Parameter einen zusätzlichen Unterstrich, wenn sie lediglich zum Setzen gebraucht werden (was bei mir quasi nur im Konstruktor der Fall ist, Setter habe ich auch sehr wenige). Denn den Parameter brauche ich genau einmal zum Setzen und danach nie wieder. Dann plag ich mich nicht mehr mit den Unterstrichen rum.

Jup, so löse ich den Konflikt in Konstruktoren auch (nur habe ich den Untersrich vorne).

volkard

Eisflamme schrieb:

Hast Du Lust mit Nexus zu diskutieren, ob kein Prä/Suffix besser ist

Nö.

Eisflamme schrieb:

oder ist das jetzt reine Geschmackssache so wie einer eben Erdbeereis und der andere lieber Schokolade mag (, obwohl das Beispiel schlecht ist, da man auch beides essen kann).

Jup. Schokoeis mag ich lieber.

this-*gt*that

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) { }

Shade Of Mine

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?

volkard

Shade Of Mine schrieb:

Meine Ctors sehen so aus:
Foo(int bar) : bar(bar) {}
Wo genau siehst du hier ein Problem?

Manchmal muß da eine Bwerechnung rein.

Hashtable(size_t size) : size(size<=101?101:getLowerPrimeTwinNotBelow(size)) {}

So Rechendinge habe ich lieber im Funktionsblock. Auch, weil ich ?: nicht mag.
Mit size_ ist meine einzige Überlegung "Ich bin in einem Kostruktor, also hat der Übergabeparameter einen _."
Ohne den Trick sind meine Überlegungen vielfältiger, in der Initialisiererliste geht's direkt, unten muß this-> benutzt werden.

edit: Beispiel ist schlecht, denn der wahre Name des Übergabeparameters hier ist ist minSize. Bin am Überlegen, ob man bei gleichen Namen immer die Initialisiererliste für die gleichnamigen benutzen kann. Jo, vielleicht schon. Muß mir mal versuchen, das anzugewöhnen.

yahendrik

Dravere's Beitrag kann ich voll und ganz zustimmen: Visual Assist (das jeden Cent wert ist) fügt nach einem m und anschließend gedrückter Shift-Taste automatisch einen Unterstrich ein, die Member einer Klasse werden komplett in der Intelli-Sense angezeigt. Wenn man schon so ein tolles Tool nutzt, warum sollte man nicht von dessen Fähigkeiten profitieren?
Aber die Pioniere haben auch verschiedene Vorstellungen. Soweit ich das überblicke:
Bjarne Stroustrup : eher keine Präfixe/Suffixe
Herb Sutter : Suffix _
Scott Meyers : m_
Aber ist die ganze Diskussion nicht völlig überflüssig?

CStoll

Bei den Quelltexten, die ich vor die Finger bekomme, gibt es keinen einheitlichen Stil. Die meisten haben keine besonderen Unterscheidungsmerkmale (ich hab' auch schon geschafft, versehentlich eine Instanzvariable zu überdecken, als ich eine vorhandene Klasse ergänzen durfte), teilweise gibt es auch die Schreibweise mit zwei Unterstrichen^*.

In den C#-Projekten hat mein Vorgänger Member mit Unterstrich (und die zugehörigen Properties ohne Unterstrich) verwendet.

^*die Sprache hat keine Zugriffsspezifikationen (d.h. alles ist public), aber der Code-Assistent spart Namen mit __ aus bei der Code-Vervollständigung aus.

DrGreenthumb

Shade Of Mine schrieb:

Meine Ctors sehen so aus:
Foo(int bar) : bar(bar) {}
Wo genau siehst du hier ein Problem?

da steht bar = bar.

Welches bar kriegt foo? Foo(int bar, int foo): bar (foo), foo (bar) {}
Ist natürlich kein Problem wenn man C++ kann.

Ich bevorzuge int size() {return _size;}

hustbaer

Eisflamme schrieb:

es gibt ja diese m_-Variante, die aber laut irgendeinem Thread so aussieht, als wär man ein Anfänger.

Unsinn.
Ich verwende überall m_. Sogar in C# Projekten.
Ich finde es sehr praktisch auf den 1. Blick zu sehen wenn irgendwo State der Klasse angegriffen wird.
Mal ganz davon abgesehen dass diese Konvention von wirklich vielen vielen Projekten genutzt wird.

Abgesehen von "gar kein Prefix" ist es vermutlich die am häufigsten genutzte Variante. (Möglicherweise sogar häufiger als "gar kein Prefix", aber da bin ich mir nicht sicher.)

Dann gibt es eine my-Variante, die finde ich persönlich aber nicht so hübsch. Wirkt einfach zu materiell motiviert.

Ja, my. *würg*
Und nicht zu vergessen "its". *doppel-würg*
(BTW: wenn ich zwischen "its" und "my" wählen müsste, dann ganz klar "my" - man greift auf Member ja normalerweise öfter aus Memberfunktionen der eigenen Klasse zu als von sonst wo. "its" ist da total dämlich, "my" trifft es viel besser. Es heisst ja auch "this" und nicht "it".)

Irgendwer kommt irgendwann sich auch noch auf die Idee "her" für Klassen und "his" für structs zu verwenden oder dergleichen

Also habe ich bis vor kurzem _ als Suffix benutzt.

Hmmm...
Naja. Finde ich nicht so toll. Zu schlecht sichtbar. OK, besser als nix, aber ... hm. Ne

hustbaer

Shade Of Mine schrieb:

Allerdings ist mir gerade das ab und zu eine Hilfe, um schneller zu erkennen, dass ich am Klassenstatus hantiere.

Das ist uebrigens die selbe Argumentation die fuer ungarische Notation verwendet wird.

Macht ja nix.

Anderes Thema, andere Vor- und Nachteile. Ein Vorteil ist der selbe. Viele Nachteile fallen weg.
Dass es die selbe Argumentation ist, wie die die üblicherweise verwendet wird um die UN zu "rechtfertigen", besagt also rein gar nichts. Auch nicht wenn man davon ausgeht dass UN grober Unfug ist (wie ich das z.B. tue).

Für mich persönlich ist es viel wichtiger zu sehen was Object-State ist und was nicht, als zu sehen welchen Typ irgendwas hat. VIEL wichtiger. VIIIIIIEL.

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).