Benamung von Variablen

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.

asc

Xin schrieb:

volkard schrieb:

Das ist der von mir genannte Fall, der Konstruktor. Ich habe die Kollission nur in Konstruktoren...

Ich habe viele Klassen, also hätte ich auch viele Kollisionen...

Viele Klassen heißt noch immer nicht das es hier viele Kollisionen gäbe, selbst bei der Verwendung von Settern hält es nach meiner Erfahrung stark in Grenzen. Und die Projekte an denen ich arbeite, haben in der Regel sehr viele Klassen und sind zumindest keine ganz kleinen Projekte (Minimum ca. 250.000+ Codezeilen).

Xin

Eisflamme schrieb:

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.

Das ist ja gar nicht erforderlich, das kann heute ja auch durchaus der Fall sein: Wie gesagt: Ich habe VC10 und einen nicht ganz hoffnungslos veralteten gcc 4.4 gefragt. Ich bin also sicher, dass VC12 und gcc 4.8 das auch noch können und clang und Intel da auch nicht nachsteht.

Damit fällt (eventuell) ein Argument dafür weg - die anderen bleiben aber bestehen, weswegen ich das weiterhin guten Gewissens empfehlen kann. Und das war die Frage: "Wie würde man eine Variable 'benamen'".

Ich mach das ja auch nicht, weil ich das ausgewürfelt habe, sondern weil die Stile, die ich in den ersten zehn Jahren gepflegt habe, halt mehr Nachteile hatten.
Auch heute versuche ich immer mal wieder Neues. In den letzten zehn Jahren hat sich aber nichts mehr durchgesetzt, die stilistischen Experimente werden dann bei Aufräum-Aktionen passend zurückgebaut. Die einzige Neuerung ist eine Änderung im Klassenaufbau, was die Reihenfolge der Einträge bestimmt: Relationen, Typen, Member, Konstruktion, Operatoren, Methoden mit entsprechenden Trennkommentaren. Dahin baue ich derzeit hunderte Klassen um.

Wegen der nun funktionierenden Initliste werde ich mein Framework nicht ändern, denn optisch macht die Zuweisung von item auf item immernoch keinen Sinn, auch wenn der Compiler hier eine andere Semantik versteht, als die augenfällige.
Die Initliste verwirrt (mich) mit item(item) mehr als sie nutzt und inhaltlich zeigt sie sich damit noch fragwürdiger als sie für die direkte Initialisierung von Variablen sowieso schon ist.

asc schrieb:

Xin schrieb:

Ich habe viele Klassen, also hätte ich auch viele Kollisionen...

Viele Klassen heißt noch immer nicht das es hier viele Kollisionen gäbe,

Gibt es aber, ich arbeite gerne mit Wrappern, um die semantische Codeanalyse gut nutzen zu können.

asc schrieb:

Und die Projekte an denen ich arbeite, haben in der Regel sehr viele Klassen und sind zumindest keine ganz kleinen Projekte (Minimum ca. 250.000+ Codezeilen).

Ich glaube nicht, dass ich (privat) inzwischen 250k LOC erreicht habe, ich habe aber auch lange nicht mehr nachgemessen. Vor zwei Jahren waren es rund 150k, inzwischen dürften es... mehr sein. Keine Ahnung, LOC ist für mich kein Maß, weil ich viel Zeit investiere, Code zu komprimieren und sich diese Arbeit sich damit zeigt, dass man in LOC gemessen nach der Arbeit weniger getan hat als bevor man Zeit investiert hat.

Ich sage aber auch ganz ehrlich - mir ist vollkommen egal, ob mein Vorgehen Erfahrungen anderer entspricht. Es entspricht meinen Erfahrungen. Und ich entwickle, um meine Probleme zu lösen.
Andere Entwickler lösen andere Probleme und kommen dabei eventuell zu anderen Präferenzen, das ist für mich okay.

Nur der Wunsch, dass es nur eine Wahrheit in diesem Forum geben darf, nervt mich etwas, denn wenn andere schon wissen, wo ich Schmerzen habe, ohne dass sie mich die letzten 20 Jahre begleitet haben, dann habe ich einen Wunderheiler oder einen Sektengründer vor mir. Ich weiß gelegentlich auch bei Anfängern, wo der Schuh drückt, ohne mir deren Code angesehen zu haben. Ich bin aber kein Anfänger mehr.

volkard schrieb:

Und ich sage Dir, daß Du nicht richtig überlegt hast. Die andere Version ist viel schmerzfreier.

Ich aber sage Dir, Du darfst davon ausgehen, dass ich inzwischen passgenaue Sportschuhe mit Stahlkappen trage - da drückt nix mehr und ich schieße mir auch nicht mehr selbst in den Fuss. Ich habe 1986 angefangen zu programmieren, seit 1994 in C++, ich arbeite als C++ Entwickler. Ich bin mir ziemlich sicher, dass ich vieles, was meinen Schmerz beim Programmieren lindert, bereits getan habe. Mein Programmierstil ist hierbei eine zusätzliche Einlegesohle - das ist keine spontane Entscheidung gewesen und ich denke, dass ich damit mehr beschäftigt habe, als die meisten anderen.
Passt schon

knivil

Ein "Ding" hat möglichst genau einen Namen und wenn es den nicht hat, dann meine ich auch etwas anderes.

Nun, da bin ich ehe Mathematiker: Namen sind Schall und Rauch. Was ein Ding ist, wird durch den Typ bestimmt. D.h. ein event/event/event_t wuerde bei mir e oder evt heissen. Obwohl ich den stl-Stil benutze, d.h. var_names_with_underscore, ist die Namensfindung kein Problem. Bei CamelCase sind Typen meist gross am Anfang, waehrend Variablen am Anfang klein geschrieben werden. So koennen Typ und Variable "gleich" benannt werden.

List <Veranstaltung> ListeVeranstaltungen;

Sowas wuerde bei mir wahrscheinlich

List<Event> es/events

heissen. Dabei wuerde ich die Namenskonventionen der jeweiligen Programmiersprache uebernehmen, meist durch die Standardbibliothek ersichtlich. Schaut man in anderen Programmiersprachen wie Lisp/Scheme/Haskel, so ist es nicht unueblich einfach ls, es, cs, ... zu benutzen. Dabei muss es sich nicht zwingend um eine Liste handeln, das zusaetzliche 's drueckt einfach nur die Mehrzahl aus. D.h. auch std::vector/set/unordered_set<event> es ist bei mir ueblich.

Xin

knivil schrieb:

Ein "Ding" hat möglichst genau einen Namen und wenn es den nicht hat, dann meine ich auch etwas anderes.

Nun, da bin ich ehe Mathematiker: Namen sind Schall und Rauch.

Wenn man da eine Regel gefunden hat, an die man sich einfach halten kann, so dass einem der Name bewusst wird, ohne dass man nachgucken muss, hast Du dieses Problem anders gelöst.

Ich versuche im Idealfall Namen zu finden, die ich mir ohne Nachzugucken merken kann. Darum heißt das Event bei mir eben Event, ein Array<Event> bevorzugt Events und eine List<Event> EventList. Bevorzugt... nobody's perfect
Auch hier besteht durchaus noch Bedarf an meinem Framework Dinge zu vereinheitlichen. ^^
Das sind so Dinge, die sich mit der Zeit herausgebildet haben, wo ich aber trotzdem weiß, wie es heißen muss und was ich in den Fingern habe.

Ich persönlich habe Schwierigkeiten mir Namen zu merken - wie Du sagtest: Namen sind Schall und Rauch - merke ich mir nicht, ich kann es mir nicht merken. Also muss ich sie herleiten können. Ich denke in Datenstrukturen, ich kann also gut mit Datentypen und wenn ich weiß, wofür ich diese Datentypen brauche, dann weiß ich auch, wie ich sie nenne und damit auch den Variablennamen für den passenden Member.

Ich denke, die Programmierstile sind unterschiedlich, weil Entwickler auch unterschiedliche, individuelle Stärken und Schwächen haben. Ich mag keine Prosa, kann aber einen Algorithmus auch nur schlecht lesen, wenn alle Variablen a, b, c, i, j, k, x, y, z sind. Einstellige Variablen sind für mich Zählvariablen, Temporärvariablen: Schall und Rauch.
Aus e->d und e->l kann ich nicht erkenne, dass das Event ein Date und eine Location hat und obwohl es super zu schreiben ist, ist es (für mich) kacke zu lesen. veranstaltung->veranstaltungsort ist einfacher zu lesen, dafür habe einen halben Roman da stehen. Der Roman verdeckt mir die optische Struktur vom Algorithmus, was es für mich schwerer schnell durch den Quelltext zu scrollen und eine bestimmte Stelle zu finden.
Daher halt kurze, prägnante, englische Namen und nur wenige standardisierte Abkürzungen.
Englisch zum Beispiel, damit ich während meiner deutschen Gedanken, nicht durcheinander komme mit Veranstaltung, der Datenstruktur und Veranstaltung, der zu organisierendem Party. Das eine ist das Event-Datenstruktur, das andere die Veranstaltung.

So entstehen unterschiedliche Präferenzen und Stile, die vermutlich jeder andere absolut schrecklich findet und total falsch findet. Geht mir auch so.
Deswegen sehe ich bei Programmierstilen kein Falsch, kein Richtig, sondern nur Möglichkeiten und jeder sucht sich raus, was für die eigenen Stärken und Schwächen effektiv funktioniert.

Nathan

Xin schrieb:

veranstaltung->veranstaltungsort ist einfacher zu lesen, dafür habe einen halben Roman da stehen.

Wobei sowas bei mir eher veranstaltung->ort schreibe.

Shade Of Mine

Xin schrieb:

Eisflamme schrieb:

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.

Das ist ja gar nicht erforderlich, das kann heute ja auch durchaus der Fall sein: Wie gesagt: Ich habe VC10 und einen nicht ganz hoffnungslos veralteten gcc 4.4 gefragt. Ich bin also sicher, dass VC12 und gcc 4.8 das auch noch können und clang und Intel da auch nicht nachsteht.

Ich wuesste nicht wann es je anders gewesen waere.
Vielleicht vor 1998 in einem obskuren Compiler?

PS:
Mich warnt mein Compiler wenn ich ausversehen eine falsche Variable erwische mit einer Zuweisung. Deshalb ist mein Stil auf lesbarkeit getrimmt.

Ich kann wenn ich ein Statement sehe erkennen was Variablen, was Typen und was Funktionen sind. Das ist enorm praktisch. Denn es geht darum den Code so schnell wie moeglich zu verstehen - Fehler werden durch den Compiler (Warnungen) verhindert.