Der _

[Shade Of Mine]

Zeus schrieb:

Und nun?

get/set verwenden?

[asc]

Shade Of Mine schrieb:

was bringt mir eine kennzeichnung der member variablen? das klingt so sehr nach polnische notation und das klingt furchtbar.

Dem kann ich mich auch nur anschließen. Meiner Erfahrung nach führt dies auch zu ein leicher lesbaren Code - aber Geschmäcker sind verschieden (Macht den Stil in eurer Firma/Projekt aus).

cu André

[Zeus]

Shade Of Mine schrieb:

Zeus schrieb:

Und nun?

get/set verwenden?

Die sind doch da?

Wieso soll ich Membervariable Kennzeichnen?
Wieso soll ich Getter/Setter Kennzeichenen?

Das sind Fragen, die man nicht im Einzelen beantworten, sondern im Ganzen.

[Gröhler]

Shade Of Mine schrieb:

Zeus schrieb:

Und nun?

get/set verwenden?

Dann ist das, das gleiche Argument wie "für _".

@all!
Übrigens, wir benutzen in unseren Java-Projekten (ja!) für Member-Variablen einen vorangestellten Unterstrich!!! Hier zu pauschalisieren, das alle Java-Projekte keine Unterstriche verwenden, ist ja auch genial.

[SideWinder]

Gröhler schrieb:

@all!
Übrigens, wir benutzen in unseren Java-Projekten (ja!) für Member-Variablen einen vorangestellten Unterstrich!!! Hier zu pauschalisieren, das alle Java-Projekte keine Unterstriche verwenden, ist ja auch genial.

Damit seid ihr aber sicher die Ausnahme die die Regel bestätigt.

Zeus schrieb:

Wieso soll ich Getter/Setter Kennzeichenen?

Methodennamen sind Verben und sollen eine Tätigkeit darstellen. In diesem Fall "bekomme variable" also "getVar()" bzw. "getvar()" oder wie auch immer. Während Size den Klassentyp darstellt und size eine Instanz davon.

MfG SideWinder

[Shade Of Mine]

natürlich kann man _ verwenden um hausgemachte probleme zu beseitigen - aber worum es mir geht ist, eine prinzipielle verwendung von _ oder m_
denn viele verwenden das, genauso wie C oder T als ersten buchstaben im klassen namen - "weil man es eben so macht".

wenn man namenskonflikte hat, muss man sie lösen.

ich verwende auch _ wenn ich diese komische c++ library konvention einhalten muss, weil es nicht anders geht. aber dann markiert der _ ja keine membervariable, sondern er umgeht namenskonflikte (das ist ein großer unterschied).

[SideWinder]

Außerdem macht ein führender Unterstrich meistens das IntelliSense schwächer, da ich zumindest zwei Buchstaben schreiben muss (_ + Anfangsbuchstabe) um dann mit CTRL+SPACE zu erweitern.

MfG SideWinder

[asc]

Zeus schrieb:

Das sind Fragen, die man nicht im Einzelen beantworten, sondern im Ganzen.

Gut, ich nenne dir mal meine Konventionen:

b) Ich verwende "CamelCase" für Klassen, Methoden, Funktionen und "pascalCase" für Variablennamen (unabhängig vom scope)
a) Ich bennene Variablen und Funktionen sprechend (unabhängig vom scope) nach ihren Aufgaben. Bei Funktionen gehört dazu was die Funktion macht - die einzige Ausnahme bei mir sind getter für Boolische Typen. Die heißen tatsächlich identisch wie die Variablen, nur die Groß/Kleinschreibweise unterscheidet sich (Da ich ein IsXXX in dem Fall für sprechender als ein GetXXX halte).
Beispiel: isPersistent, adresse, IsPersistent, GetAdresse, Delete...

Ich finde eine Funktion die Adresse() heißt nunmal nicht sprechend. Da fehlt noch immer was mit der Adresse gemacht wird, daher kommt man eigentlich (wie gesagt mit Ausnahme der Boolean) niemals in Konflikt mit Variablennamen, da es dann zwangsweise mindestens GetAdresse() heißen muss.

cu André

[Gröhler]

Shade Of Mine schrieb:

ich verwende auch _ wenn ich diese komische c++ library konvention einhalten muss, weil es nicht anders geht. aber dann markiert der _ ja keine membervariable, sondern er umgeht namenskonflikte (das ist ein großer unterschied).

Dem kann ich nur zustimmen. Ich verwende mittlerweile allerdings ein vorangestelltes my_ für Membervariablen. Hatte immer _ benutzt, war aber für mich schwer zu lesen. Die _ hatte ich aber auch nur benutzt, weil ich Namenskonflickte hatte. Das geht leider nicht anders:

class A
{
     string name;
public:
     void rename(string m);
     string name(); // Namenskonflickt
};

Also Unterstrich bzw. my_.

[Erhard Henkes]

So langsam bin ich doch für this.

[Nexus]

Shade Of Mine schrieb:

was genau ist der sinn von sowas?
m_foo ist furchtbar weil es intellisense erschwert
foo ebenso nur ist es kürzer und daher besser
foo ist ok, weil es intellisense nicht zerstört aber ich sehe den sinn nicht.

SideWinder schrieb:

Außerdem macht ein führender Unterstrich meistens das IntelliSense schwächer, da ich zumindest zwei Buchstaben schreiben muss (_ + Anfangsbuchstabe) um dann mit CTRL+SPACE zu erweitern.

Manchmal finde ich das für das Intellisense aber auch gut. Nehmen wir einmal an, man kennt etwas aus der STL nicht genau und will dessen Funktionen nachschlagen. Da kann man std::deque:: eintippen und da kommt die schöne Liste der Memberfunktionen. Da die privaten und nicht benötigten Funktionen dank _ am Anfang unten in der Liste stehen, hat man einen besseren Überblick.

Ich selber verwende bei privaten Variablen eigentlich keinen _ vorne, sondern nur einen grossgeschriebenen Namen, der auch gut kennzeichnet, wofür die Variable steht. Bei Parametern setze ich oft "New" vorne dran. Aber ich programmiere eher freizeitmässig und habe auch keine gigantischen Projekte; bei meinen eigenen Projekten weiss ich also meistens, was wofür steht. Zum Beispiel:

class MyClass
{
private:
   int Style;
public:
   int GetStyle() const;
   void SetStyle(int NewStyle);
};

Allerdings habe ich bei einigen kleinen Vorlageheaders, die ich eher zur Übung programmiert habe (z.B. ein Containertemplate) die wenigen privaten Member mit _ und Abkürzungen bezeichnet, da man diese oft braucht und sie eben beim IntelliSense hinten stehen (z.B. _ptr , _dim ). Im Allgemeinen werde ich jedoch private Member im Normalfall wie oben bezeichnen.

Erhard Henkes schrieb:

So langsam bin ich doch für this.

Das finde ich unschön. Meiner Ansicht nach ist es besser, wenn sich die Namen von Membervariablen und Parametern klar unterscheiden. Dann kann man auch das this-> weglassen, ohne immer Angst haben zu müssen, dass etwas anderes gemeint sein könnte.

Ihr seht, ich bin mir selber nicht ganz sicher ;). Momentan mache ich die Variante wie im Code oben und fahre eigentlich gut damit. Falls ich in Zukunft aber auf Probleme stosse, steige ich wahrscheinlich auf MyStyle oder myStyle um.

[Erhard Henkes]

Wie soll man wissen, was hier wirklich optimal ist, wenn selbst ein C++-Guru wie Herb Sutter Unterstriche verwendet und diese wegen des Standards von vorne nach hinten verlagert.

[Gröhler]

Erhard Henkes schrieb:

Wie soll man wissen, was hier wirklich optimal ist, wenn selbst ein C++-Guru wie Herb Sutter Unterstriche verwendet und diese wegen des Standards von vorne nach hinten verlagert.

Ein Profi sollte auch Entscheidungen treffen können. Egal ob es eine perfekte Lösung ist.

[Nexus]

Erhard Henkes schrieb:

Wie soll man wissen, was hier wirklich optimal ist, wenn selbst ein C++-Guru wie Herb Sutter Unterstriche verwendet und diese wegen des Standards von vorne nach hinten verlagert.

Ich wollte hier weder jemandem meine Schreibweise aufzwingen noch sie als absolut oder optimal bezeichnen, sondern nur zeigen, wie ich es mache, und dass ich es grundsätzlich nicht schlecht so finde. Und ich denke, das trifft auch für die meisten anderen Poster hier zu...

In diesem Thread geht es wohl eher darum, verschiedene Möglichkeiten zu diskutieren. Klar gibt es nicht den einzig richtigen Ansatz.

[Profi-Programmierer]

Ihr n00bs, richtig macht man das wenn schon so:
mFoo
denn:
1. Man muss nur eine Taste drücken statt zwei für den Unterstricht oder gar drei für m_
2. Wenn man die Markierung an das Ende setzt kann man sie auch gleich weglassen.
3. Eigentlich totaler quatsch, wenn man nicht mal mehr weiß was eine Membervariable ist und was nicht, dann hat der Code ganz andere Probleme.
Um in getter und setter die gleichen Namen zu verwenden gibt es zwei Möglichkeiten:
a) Man hängt an den Parameter ein _ an (davor, danach ist wie gesagt quatsch) oder etwas ähnliches (z.B. p)
b) Man verwendet die gleichen Namen und benutzt this->, indem man einfach den Code Generator der IDE nutzt

[Gröhler]

Profi-Programmierer schrieb:

b) Man verwendet die gleichen Namen und benutzt this->, indem man einfach den Code Generator der IDE nutzt

Nein, ebend nicht. Gleicher Name geht nicht wegen Namenskoonflikten! Es geht nicht um den Scope sondern um Compile-Fehler!

[Nexus]

Profi-Programmierer schrieb:

Ihr n00bs, richtig macht man das wenn schon so:
[...]

Leute mit so freundlichem Umgangston und dann noch derart schlagfertigen und ausführlich begründeten Argumenten sind generell nicht ganz ernst zu nehmen...
(Habt ihr gewusst, mit "m" am Anfang kann man sich Tasten sparen... Ich benutz ab jetzt nur noch Abkürzungen für Variablen und #defines für lange Schlüsselwörter :p).

[asc]

Profi-Programmierer schrieb:

Ihr n00bs, richtig macht man das wenn schon so:
mFoo

Ahh, ein Experte der den Begriff Noob einsetzt, und die einzig wahre Lösung^TM hat.

Ein Profiprogrammierer wüsste das die Realität anders aussieht, und selbst innerhalb einer Firma Abweichungen beim Styleguide über Projekte hinweg durchaus im Rahmen des Möglichen sind.

Profi-Programmierer schrieb:

3. Eigentlich totaler quatsch, wenn man nicht mal mehr weiß was eine Membervariable ist und was nicht, dann hat der Code ganz andere Probleme.

Warum sollte dies wichtig sein? Wenn man die Information braucht, kann man auch this-> davor schreiben (Was in der Regel auch dazu führt das eine IDE die Member auflistet so das dies nicht einmal deutlich mehr Tipaufwand bedeuten könnte). Warum irgendwelche wie auch immer gearteten Präfixe oder Postfixe nutzen? Ich sehe darin keinen Sinn (Lesbarer wird der Code davon auch nicht).

Wenn man sich ohnehin an ein paar allgemeine Regeln hält, wie z.B. das Funktionen nicht zu lang werden sollten (Im Idealfall mit einen Blick erfassbar sind), kommt das Scopeproblem in der Regel auch nicht zum tragen. Wer mit ewig langen Funktionen arbeitet macht eh etwas falsch.

Profi-Programmierer schrieb:

Um in getter und setter die gleichen Namen zu verwenden gibt es zwei Möglichkeiten:...

Mindestens die dritte übliche unterschlägst du: Man nennt Funktionen nach ihrer Funktion.

cu André

[Erhard Henkes]

oder etwas ähnliches (z.B. p)

Das kleine p sollte man wirklich nur für "pointer" verwenden, nicht für "parameter". "pBlaBla" sollte ein Zeiger auf "BlaBla" sein.

[Profi-Programmierer]

Nexus schrieb:

Profi-Programmierer schrieb:

Ihr n00bs, richtig macht man das wenn schon so:
[...]

Leute mit so freundlichem Umgangston und dann noch derart schlagfertigen und ausführlich begründeten Argumenten sind generell nicht ganz ernst zu nehmen...
(Habt ihr gewusst, mit "m" am Anfang kann man sich Tasten sparen... Ich benutz ab jetzt nur noch Abkürzungen für Variablen und #defines für lange Schlüsselwörter :p).

Oh mann was bist du für ein n00b.
Also: das m hat nicht nur den Vorteil kürzer zu sein und eine deutlich stärkerer Assoziation zu Member zu haben, es verhindert auch die Standardproblematik vollständig.

Die anderen Postings habe ich zur Kenntnis genommen und die angesprochenen Punkte sind auch richtig, allerdings sehe ich nicht inwiefern sie einem meiner Punkte widersprechen würden bzw. überhaupt mit diesen kollidieren.

Obwohl zum "p": war doch nur ein Beispiel und da sind wir auch schon wieder beim Thema warum sollte man einen Zeiger mit p kodieren? Auch hier sehe ich keinen Grund wie bei den Membern. Wenn man nicht mehr weiß was ein Zeiger ist hat der Code ganz andere Probleme.