Der _

asc

princess schrieb:

also ich hab mir heut ma das style guide von der uni reingezogen und "guter/sauberer/ code sieht bei membern so aus:

Aber nur laut deiner Uni. Es gibt hier mehrere Geschmäcker, ich lehne z.B. jegliche Unterstriche in Variablennamen ab und ergänze Membervariablen auch nicht um irgendwelche Kürzel etc. (Wenn man die Unterscheidung braucht gibt es immer noch this->).

Dies ist aber auch nur eine von vielen Meinungen.

Erhard Henkes

Wenn man die Unterscheidung braucht gibt es immer noch this->

Das ist ja wohl der letzte Ausweg.

this->blaBla

DEvent

Erhard Henkes schrieb:

class Complex {
    public:
        Complex( double real, double imaginary = 0 )
          : _real(real), _imaginary(imaginary) {};

        void operator+ ( Complex other ) {
            _real = _real + other._real;
            _imaginary = _imaginary + other._imaginary;
        }

        void operator<<( ostream os ) {
            os << "(" << _real << "," << _imaginary << ")";
        }
        //...

In den MFC wurde m_BlaBla verwendet. Herb Sutter hat einfach das m (für "member") entfallen lassen.

Das macht echt Sinn
Ansatt es _logischerweise_ so zu machen:

class Complex {
    public:
        Complex( double _real, double _imaginary = 0 )
          : real(_real), imaginary(_imaginary) {};

        void operator+ ( Complex _other ) {
            real = real + _other.real;
            imaginary = imaginary + _other.imaginary;
        }

        void operator<<( ostream _os ) {
            _os << "(" << real << "," << imaginary << ")";
        }
        //...

In dieser Variante muss man das "_" naemlich wesentlich weniger mitschreiben.

Erhard Henkes

--

Quellcode

Da das alles nur Style-Zeug ist brauch ich das vorerst nicht zu beachten.
Zum Glueck gibt es immer solche kleinen Details, über die sich Leute streiten können.
Und zum Glueck habe unsinnige Streitereien auch einen Sinn.
Ihr finanziert das Forum damit^^

hustbaer

Quellcode schrieb:

Da das alles nur Style-Zeug ist brauch ich das vorerst nicht zu beachten.

Fang lieber gleich damit an, was man sich mal angewöhnt hat gewöhnt man sich schwer wieder ab. Und "stillos" zu programmieren ist eine Sache die man sich IMO gleich garnicht angewöhnen sollte.

Shade Of Mine

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.

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

folgender code funktioniert übrigens:

explicit Complex( double real, double imaginary = 0 )
        : real(real), imaginary(imaginary) {}

PS:
in java schafft man es ja auch ohne m_ auszukommen...

SideWinder

FULL ACK Shade

MfG SideWinder

Zeus

Complex( double real, double imaginary = 0 )  : real(real), imaginary(imaginary) {}

public:
 double real() {
    return real;
 }
 void real(double real) {
    this.real = real;
 }
 double imaginary() {
    return imaginary;
 }
 void imaginary(double imaginary) {
    this.imaginary = imaginary;
 }

private:
double real;
double imaginary;

Und nun?

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.

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é

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.