Benamung von Variablen
-
Einfach
veranstaltungen
-
Eisflamme schrieb:
Einfach
veranstaltungen
+1
-
Wie wärs mit Fred?
-
In C# wäre _veranstaltungen üblicher.
-
Benamung von Variablen
Ich hab auf den ersten Blick gelesen: Besamung von Variablen
-
ich bin ein perverser? schrieb:
Benamung von Variablen
Ich hab auf den ersten Blick gelesen: Besamung von Variablen
Ich auch!
-
__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
-
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.
-
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?
-
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?
-
Eisflamme schrieb:
Einfach
veranstaltungen +2(Und ganz am Rande: selbst in C# wäre dies kein ungewöhnlicher Stil).
-
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".
-
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.
-
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.
-
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.
-
Konfikt auf, wo Parameter und Member gleich heißen, typischerweise im Konstruktor.
Konstruktor: Initialisierungsliste
Methode: explizites qualifizieren durch this.
-
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.
-
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?
