Benamung von Variablen

__I_list<__V, __Alloc<__V>> __vs;

STL Style.

STL schrieb:

__I_list<__V, __Alloc<__V>> __vs;

STL Style.

Die STL hat aber auch allen Grund dazu Variablen genau so zu benennen.

resharp schrieb:

In C# wäre _veranstaltungen üblicher.

Nicht wirklich

volkard

khjkhjk schrieb:

STL schrieb:
__I_list<__V, __Alloc<__V>> __vs;
STL Style.
Die STL hat aber auch allen Grund dazu Variablen genau so zu benennen.

Nö, nur für die doppelten Unterstriche haben sie einen Grund.
Nicht für die nichtssagenden Namen.

berniebutt

1. Auch ich hatte sofort Besamung gelesen.
2. Die Unterstriche waren einmal wichtig zur Vermeidung von Namenskonflikten. Heute nicht mehr unbedingt nötig.
3. Wer vetritt noch die Ungarische Notation?

volkard

berniebutt schrieb:

2. Die Unterstriche waren einmal wichtig zur Vermeidung von Namenskonflikten. Heute nicht mehr unbedingt nötig.

Also darf ich meine Makros endlich __V und __vs nennen?

asc

Eisflamme schrieb:

Einfach veranstaltungen

+2

(Und ganz am Rande: selbst in C# wäre dies kein ungewöhnlicher Stil).

Xin

blurry333 schrieb:

Hallo,
List <Veranstaltung> ListeVeranstaltungen ;
wie würdet ihr die Variable benennen ? Ich würd sie ja am liebsten auch Veranstaltungen nennen da ab der Typ schon so heisst geht das ja nicht.

In meinem Style wäre es "events" (als lokale Variable, Parameter), außer es wäre ein Klassenmember, dann wäre es "Events".

volkard

Xin schrieb:

blurry333 schrieb:
Hallo,
List <Veranstaltung> ListeVeranstaltungen ;
wie würdet ihr die Variable benennen ? Ich würd sie ja am liebsten auch Veranstaltungen nennen da ab der Typ schon so heisst geht das ja nicht.
In meinem Style wäre es "events" (als lokale Variable, Parameter), außer es wäre ein Klassenmember, dann wäre es "Events".

Das löst nur den selteten Konfikt auf, wo Parameter und Member gleich heißen, typischerweise im Konstruktor.

Xin

volkard schrieb:

Das löst nur den selteten Konfikt auf, wo Parameter und Member gleich heißen, typischerweise im Konstruktor.

Bei mir ist dieser Konflikt regelmäßig, um nicht zu sagen, nahezu grundsätzlich.

Gleichzeitig kann eine lokale Variable oder ein Parameter keinen Member verstecken, ohne dass ich this-> oder irgendeine andere Kennung wie m oder _ davor schreiben müsste.

Der einzige Nachteil ist, dass gut benannte Datentypen in der Regel ausdrücken, was sie repräsentieren. "Event Event" hakt halt, aber das ist mit "::Event Event" klarzustellen.

volkard

Xin schrieb:

volkard schrieb:

Das löst nur den selteten Konfikt auf, wo Parameter und Member gleich heißen, typischerweise im Konstruktor.

Bei mir ist dieser Konflikt regelmäßig, um nicht zu sagen, nahezu grundsätzlich.

Beispiel?

Bei mir ist es genau andersrum, "FooFactory fooFactory" habe ich regelmäßig.

knivil

Konfikt auf, wo Parameter und Member gleich heißen, typischerweise im Konstruktor.

Konstruktor: Initialisierungsliste
Methode: explizites qualifizieren durch this.

Xin

volkard schrieb:

Xin schrieb:

volkard schrieb:

Das löst nur den selteten Konfikt auf, wo Parameter und Member gleich heißen, typischerweise im Konstruktor.

Bei mir ist dieser Konflikt regelmäßig, um nicht zu sagen, nahezu grundsätzlich.

Beispiel?

class ItemWrapper
{
  ::Item Item;
public:
  ItemWrapper( ::Item & item )
    : Item( item )             // <- da.
  {}
};

int main(void)
{
  Item item;                  // <- und da habe ich FooFactory fooFactory
  ItemWrapper iw( item );
  ...
}

Ich befinde mich aber häufiger beim Programmieren von Funktionen als bei der Definition von Klassen. knivel geht da leider wieder mit seinen Lösungen am Problem vorbei, da die Initialisierungsliste nix mit dem Problem zu tun hat und this-> im Posting zuvor bereits abgelehnt wurde, ergo expliziertes Qualifizieren eben keine bessere Lösung darstellt, weil ich häufiger Variablen als Datentypen anspreche. Als Dokumentation kann man this-> meinetwegen begründen, bei mir sind die Variablen eben groß geschrieben, was den Sachverhalt genauso dokumentiert.

An dem Wrapperbeispiel sieht man schön, wieviel Prosa C++ teilweise hat. Das werde ich mit this-> sicherlich nicht noch weiter ausdehnen. Dann schon lieber :: bei den seltener auftretenden Datentypen.

volkard

Xin schrieb:

volkard schrieb:

Xin schrieb:

volkard schrieb:

Das löst nur den selteten Konfikt auf, wo Parameter und Member gleich heißen, typischerweise im Konstruktor.

Bei mir ist dieser Konflikt regelmäßig, um nicht zu sagen, nahezu grundsätzlich.

Beispiel?
class ItemWrapper
{
  ::Item Item;
public:
  ItemWrapper( ::Item & item )
    : Item( item )             // <- da.
  {}
};

int main(void)
{
  Item item;                  // <- und da habe ich FooFactory fooFactory
  ItemWrapper iw( item );
  ...
}
Ich befinde mich aber häufiger beim Programmieren von Funktionen als bei der Definition von Klassen. knivel geht da leider wieder mit seinen Lösungen am Problem vorbei, da die Initialisierungsliste nix mit dem Problem zu tun hat und this-> im Posting zuvor bereits abgelehnt wurde, ergo expliziertes Qualifizieren eben keine bessere Lösung darstellt, weil ich häufiger Variablen als Datentypen anspreche. Als Dokumentation kann man this-> meinetwegen begründen, bei mir sind die Variablen eben groß geschrieben, was den Sachverhalt genauso dokumentiert.

An dem Wrapperbeispiel sieht man schön, wieviel Prosa C++ teilweise hat. Das werde ich mit this-> sicherlich nicht noch weiter ausdehnen. Dann schon lieber :: bei den seltener auftretenden Datentypen.

Das ist der von mir genannte Fall, der Konstruktor. Ich habe die Kollission nur in Konstruktoren. Setter meide ich übrigens. Ok, auch mal in einem Setter.
Das kann ich verschmerzen.
Haste ein anderes Beispiel aus der Praxis?

asc

Xin schrieb:

knivel geht da leider wieder mit seinen Lösungen am Problem vorbei, da die Initialisierungsliste nix mit dem Problem zu tun hat und this-> im Posting zuvor bereits abgelehnt wurde,..

Die Initialisierungsliste hat kein Konflikt bei gleicher Benennung (Und das ohne this->), ist daher durchaus etwas das mit dem Problem thematisch zu tun hat.

Eisflamme

Ich kapier das Item-Beispiel nicht, ich würde das so machen:

class ItemWrapper
{
private:
    Item item;

public:
    ItemWrapper(const Item& item) : item(item) {}

    void SetItem(const Item& item) {this->item = item;}
    // alternativ
    void SetItem(const Item& newItem) {item = newItem;}
};

Edit:
Und praktisch finde ich diese Diskussion unnötig. Weder spezielles this-> noch ein kurzes Präfix wie new stören den Lesefluss mMn.

Typen und Variablen durch Großschreibung der Variablen zu vermengen und die Notwendigkeit des :: zu haben irritiert da viel eher, finde ich. Ich halte mich lieber daran alles simpel zu halten: Der Regelfall ist, dass es keinen Namenskonflikt gibt, also kriegen meinen Variablen einen Namen, der dem üblichen Variablennamen entspricht (Kleinschreibung). Konfliktfall ist Ausnahme => Ausnahme- und nicht Regelbenennung soll abweichen

knivil

"::Event Event"

oder einfach

Event e;
Event evt;
Event msg;
Event k;
Event event_from_outer_space;

Xin

volkard schrieb:

Das ist der von mir genannte Fall, der Konstruktor. Ich habe die Kollission nur in Konstruktoren. Setter meide ich übrigens. Ok, auch mal in einem Setter.
Das kann ich verschmerzen.
Haste ein anderes Beispiel aus der Praxis?

Ich habe viele Klassen, also hätte ich auch viele Kollisionen. Setter vermeide ich ebenso.
So habe ich keine Kollisionen - und eben auch keine Probleme, dass ich versehentlich Member durch Parameter oder lokale Variablen verstecke.

Da ich das Problem nicht (mehr) habe und auch nichts verschmerzen muss, habe ich auch keine Beispiele aus der Praxis.

asc schrieb:

Die Initialisierungsliste hat kein Konflikt bei gleicher Benennung (Und das ohne this->), ist daher durchaus etwas das mit dem Problem thematisch zu tun hat.

Stimmt, 50% Rehabilitation für knivel.

Ich habe das gerade unter VC10 und g++ ausprobiert und das stimmt. Das ist allerdings nicht das erste Mal, dass ich das ausprobiert habe und als ich das zuletzt ausprobierte, funktionierte das nicht.
Allerdings wird das auch schon gut 10 bis 12 Jahre her sein.

Da passierte nämlich Folgendes:

Eisflamme schrieb:

ItemWrapper(const Item& item) : item(item) {}

item wurde item zugewiesen. Da item eine lokale Variable ist, wurde die lokale Variable item mit der lokalen Variablen item überschrieben. Dass das für die Initialisierungsliste so nicht gemeint war, mag ja sein. Das gibt's bestimmt auch einen schönen Paragrafen im Standard dazu.

Aber schlussendlich hilft mir der Standard nicht, wenn der Compiler das anders sieht. Gerade gestern habe ich zu Visual Studio mal wieder "Microsoft bestätigt, dass das ganze ein Problem auf Seiten von Microsoft ist" gelesen als ich von g++ wieder zu VC wechselte. Was auf g++ läuft, läuft nicht auf VC. Auf g++ bin ich gewechselt, um zu kontrollieren, was auf VC läuft, aber nicht auf g++... auch da wurde ich fündig (wobei MS die sinnvollere Lösung hatte, aber halt nicht standardkonform war und der g++ ablehnte das zu kompilieren...).
Meine Codes laufen immer auf mehreren Compilern.
Ich kann keine fragwürdigen Lösungen brauchen. Und Prosa auch nicht.
Daraus hat sich in den letzten 20 Jahren diese Notation ergeben, weil sie die wenigsten Schmerzen erzeugt.

knivil schrieb:

"::Event Event"

oder einfach

Event e;
Event evt;
Event msg;
Event k;
Event event_from_outer_space;

Ich mag es nicht, Synonyme zu finden. Ein "Ding" hat möglichst genau einen Namen und wenn es den nicht hat, dann meine ich auch etwas anderes. Ein Event ist bei mir eben kein evt, kein msg und EventFromOuterSpace wäre bestenfalls eine Ableitung von Event, aber in keinem Fall nur ein Event.

Eisflamme

Ich bin eigentlich ziemlich sicher, dass obige Variante bzgl. Element-Initialisierungen von allen gängigen Compilern verstanden wird. Gerne lasse ich mich aber eines Besseren belehren.

volkard

Xin schrieb:

Daraus hat sich in den letzten 20 Jahren diese Notation ergeben, weil sie die wenigsten Schmerzen erzeugt.

Und ich sage Dir, daß Du nicht richtig überlegt hast. Die andere Version ist viel schmerzfreier.
Aber naja, Du weißt jetzt bescheid, ändern wirste es nicht mehr.