Welches Prä- oder Suffix nutzt ihr für Memberattribute?



  • Hi,

    es gibt ja diese m_-Variante, die aber laut irgendeinem Thread so aussieht, als wär man ein Anfänger. Dann gibt es eine my-Variante, die finde ich persönlich aber nicht so hübsch. Wirkt einfach zu materiell motiviert.

    Also habe ich bis vor kurzem _ als Suffix benutzt. Für VisualAssist ist das eigentlich alles nicht nötig. Ohne VA kann man halt unabhängig davon, ob das ein Member oder nicht ist, den Namen eingeben und schnell etwas finden. _ hat den großen Nachteil, dass man da leicht Tippfehler macht bzw. Parameter mit Attributen verwechselt bei Gettern oder so.

    Wie macht ihr das?



  • Ich mache nichts, selbst wenn ich keine fancy Entwicklungsumgebung zur Verfügung habe. Wenn ich den Überblick verliere, dann ist Zeit über das Design nachzudenken.


  • Mod

    Meistens nichts, da ich den Überblick habe. Falls doch, dann nehme ich _ als Suffix. Das sieht einigermaßen gut aus und ist nicht viel unnötige Schreibarbeit und in den meisten Fällen auch gut scichtbar (ich habe jedoch manchmal Probleme mit der Sichtbarkeit festgestellt, wenn direkt da drauf eine Klammer folgt).

    Eisflamme schrieb:

    _ hat den großen Nachteil, dass man da leicht Tippfehler macht bzw. Parameter mit Attributen verwechselt bei Gettern oder so.

    😮 Dann nenn' eben deine Parameter anders!



  • Keine. Nameskonflikte gibt's dabei nur im Kostruktor.
    Und gelegentlich m_, wenn das Umfeld sehr microsoftig wird.



  • Eisflamme schrieb:

    Attributen verwechselt bei Gettern oder so.

    Nur selten Getter ich habe. Und dann heißen sie sogar wie Getter, nämlich getBegin(). begin() ist für mich nämlich ein Imperativ.



  • Eisflamme schrieb:

    Hi,

    es gibt ja diese m_-Variante, die aber laut irgendeinem Thread so aussieht, als wär man ein Anfänger. Dann gibt es eine my-Variante,...

    my sieht nach Anfänger aus.



  • volkard schrieb:

    Eisflamme schrieb:

    Attributen verwechselt bei Gettern oder so.

    Nur selten Getter ich habe. Und dann heißen sie sogar wie Getter, nämlich getBegin(). begin() ist für mich nämlich ein Imperativ.

    begin hätte ichnie als getter angesehen, auf jedenfall mal genauso wenig wie find. oder schreibst du auch getFindResult?



  • find() ist nach weiter Definition doch ein guter Name für nen Getter. Eben einer, der erst danach sucht. begin() hat für mich auch imperativen Charakter.

    Okay, gar kein Suffix oder Präfix find ich auch gut. Schließlich habe ich sonst auch nirgendwo irgendwas im Namen stehen, was auf den Typ/Modifizierer/Sichtbarkeit/... hinweist. 🙂

    Dann mach ich das im nächsten Projekt ohne, dankö.



  • Eisflamme schrieb:

    Okay, gar kein Suffix oder Präfix find ich auch gut.

    Finde ich nicht gut. Jedenfalls gefällt mir sowas gar nicht:

    void MyClass::SetValue(int newValue)
    {
        value = newValue;
    }
    

    Noch schlimmer finde ich this-> schreiben zu müssen, zumal man es teilweise ohne Compilerfehler vergessen kann. Und manchmal schreiben und manchmal nicht, naja. Gegen Underline-Postfixe habe ich, dass sie nicht so schnell erkennbar sind und zu komischen Konstrukten wie member_->DoThat() führen.

    Ich persönlich verwende m (nicht m_ ) als Präfix für Membervariablen.



  • Wenn find() für Dich ein Getter ist, dann ist jede seiteneffektfreie Funktion, die void nimmt und non-void zurückgibt, ein Getter.

    Ok, begin() klingt imperativ. Aber habt ihr den Mut, bei eigenen Containern getBegin() statt des stl-ähnlichen begin() zu nehmen?



  • Nexus schrieb:

    Eisflamme schrieb:

    Okay, gar kein Suffix oder Präfix find ich auch gut.

    Finde ich nicht gut. Jedenfalls gefällt mir sowas gar nicht:

    void MyClass::SetValue(int newValue)
    {
        value = newValue;
    }
    

    Tja, ist bei mir kein Problem. Setter habe ich noch viel seltener. Ich schreibe mehr goto als Setter.



  • Nexus:
    Verstehe.

    volkard:
    Deswegen schrieb ich "nach weiter Definition". Denn nach weiter Definition ist eigentlich fast alles ein getter oder setter oder gehört nicht in eine Klasse. Oder es ist eine private Methode, die Zwischenschritte erledigen soll.

    Hast Du Lust mit Nexus zu diskutieren, ob kein Prä/Suffix besser ist oder ist das jetzt reine Geschmackssache so wie einer eben Erdbeereis und der andere lieber Schokolade mag (, obwohl das Beispiel schlecht ist, da man auch beides essen kann).



  • Eisflamme schrieb:

    Wie macht ihr das?

    Garnichts.
    Diese unsitte gibts eh nur in C++ - in Java, Python, etc. verwendet man ja auch nichts.

    Ein setter sieht uebrigens bei mir so aus (falls man sowas denn mal brauchen sollte - was, wie volkard ja schon gesagt hat, nur sehr selten der Fall ist):

    void setValue(T value) {
       this->value = value;
    }
    

    PS:
    einzig wenn man die Namenskonvention der STL verwendet, dann machen sie sinn. Dann nehme ich unterstriche am Ende des Namens:

    void value(T value) {
      value_ = value;
    }
    

    Aber diese Namenskonvention mag ich nicht wirklich.



  • volkard schrieb:

    Ok, begin() klingt imperativ. Aber habt ihr den Mut, bei eigenen Containern getBegin() statt des stl-ähnlichen begin() zu nehmen?

    Das hat nichts mit Mut zu tun, sondern sorgt nur für Verwirrung, wenn man nicht nur für sich selbst programmiert.



  • volkard schrieb:

    Tja, ist bei mir kein Problem.

    Weil du dich mit newValue abfindest oder eine andere Variante verwendest (zumindest in den seltenen Fällen, in denen du Setter hast)? Wenn zweiteres, welche Variante?

    Eisflamme schrieb:

    Deswegen schrieb ich "nach weiter Definition". Denn nach weiter Definition ist eigentlich fast alles ein getter oder setter oder gehört nicht in eine Klasse.

    Schon mal sämtliche Funktionen wie vector::push_back() , SpaceShip::Explode() etc. nicht. Es sei denn, wir wollen die Begriffe Setter und Getter soweit verwaschen, dass sie ihre Aussagekraft verlieren.

    Shade Of Mine schrieb:

    Garnichts.
    Diese unsitte gibts eh nur in C++ - in Java, Python, etc. verwendet man ja auch nichts.

    Kannst du mir erklären, warum mValue = value so viel schlechter ist als this.value = value ? Gerade die Java-Standardbibliothek hat ja nicht unbedingt wenig Setter. Und die Variante mit this hat zwei Probleme: Entweder man verwendet es immer, was den Code komplizierter macht, oder man verwendet es nur in mehrdeutigen Fällen, was aber die Gefahr des Vergessens mit sich bringt (und damit kompilierende Logikfehler).

    Andererseits hat kein Präfix den Vorteil, dass auch in den eindeutigen Fällen kein m notwendig ist. Allerdings ist mir gerade das ab und zu eine Hilfe, um schneller zu erkennen, dass ich am Klassenstatus hantiere.



  • Nexus schrieb:

    Kannst du mir erklären, warum mValue = value so viel schlechter ist als this.value = value ? Gerade die Java-Standardbibliothek hat ja nicht unbedingt wenig Setter. Und die Variante mit this hat zwei Probleme: Entweder man verwendet es immer, was den Code komplizierter macht, oder man verwendet es nur in mehrdeutigen Fällen, was aber die Gefahr des Vergessens mit sich bringt (Laufzeitfehler).

    Der Compiler warnt dich wenn du das this vergisst.

    mValue hat 3 Nachteile. Der erste ist: unnoetige Info im Namen - das macht das Scannen der Variablen etwas komplizierter. Da das Schriftbild der Variablen sich kuenstlich annaehert.

    Der 2. Nachteil ist die Autovervollstaendigung. Ich muss mV+Tab tippen waehrend ich sonst nur v+Tab tippen muesste.

    Der 3. Nachteil ist, dass die Variablen nicht mehr alphabetisch korrekt einsortiert sind in den Zusatztools die man zur Source Code analyse verwendet. zB der Klassenbrowser etc. Da sind sie ploetzlich unter m zu finden anstatt unter dem korrekten Namen.

    Keine moderne Sprache hat so eine polnische Notation. Warum sollte man sie in C++ haben? this-> kann man in den sehr sehr sehr seltenen Situationen verwenden wo es einen namensclash gibt. Und wenn man es vergisst und

    void setValue(T value) {
       value=value;
    }
    

    schreibt, warnt mich eh der Compiler.

    Allerdings ist mir gerade das ab und zu eine Hilfe, um schneller zu erkennen, dass ich am Klassenstatus hantiere.

    Das ist uebrigens die selbe Argumentation die fuer ungarische Notation verwendet wird.


  • Administrator

    volkard schrieb:

    Tja, ist bei mir kein Problem. Setter habe ich noch viel seltener. Ich schreibe mehr goto als Setter.

    Shade Of Mine schrieb:

    (falls man sowas denn mal brauchen sollte - was, wie volkard ja schon gesagt hat, nur sehr selten der Fall ist):

    Könntet ihr das bitte präzisieren, würde mich wunder nehmen. Schreibt ihr Model Klassen ohne Setter? Muss man immer neue Objekte erstellen, wenn man eine Variable anpassen möchte? Ich habe so meine liebe Mühe zu glauben, dass ihr "selten" Setter verwendet. Erst recht, dass ihr goto mehr einsetzt als Setter-Funktionen.

    Ich verwende übrigens das m_ , aus den Gründen, welche Nexus genannt hat.

    Grüssli



  • Shade Of Mine schrieb:

    this-> kann man in den sehr sehr sehr seltenen Situationen verwenden wo es einen namensclash gibt

    Bei mir sind diese Situationen halt nicht so sehr sehr selten. Ich habe ab und zu Setter/Getter, wenn ich es für sinnvoll erachte. Gerade bei Low-Level-Klassen wie Sprite mit etlichen separaten Attributen (Position, Rotation, Skalierung, Farbe, Blend-Mode...) sind Setter und Getter auch sinnvoll, wenn man Kapselung haben möchte.

    Shade Of Mine schrieb:

    Das ist uebrigens die selbe Argumentation die fuer ungarische Notation verwendet wird.

    Immer schön relativieren. Im Gegensatz zur Memberzugehörigkeit sprechen bei der Typzugehörigkeit etwas gravierendere Gründe gegen den Einsatz der UN. Und davon sind auch nicht 2/3 technische oder IDE-spezifische Limitierungen.


  • Administrator

    Shade Of Mine schrieb:

    mValue hat 3 Nachteile. Der erste ist: unnoetige Info im Namen - das macht das Scannen der Variablen etwas komplizierter. Da das Schriftbild der Variablen sich kuenstlich annaehert.

    Der 2. Nachteil ist die Autovervollstaendigung. Ich muss mV+Tab tippen waehrend ich sonst nur v+Tab tippen muesste.

    Der 3. Nachteil ist, dass die Variablen nicht mehr alphabetisch korrekt einsortiert sind in den Zusatztools die man zur Source Code analyse verwendet. zB der Klassenbrowser etc. Da sind sie ploetzlich unter m zu finden anstatt unter dem korrekten Namen.

    Diese 3 Nachteile sind für mich völlig irrelevant. Das mit der Autovervollständigung finde ich im Gegenteil eher praktisch. Wenn ich eine Membervariable ansprechen will, schreibe ich schon automatisch m_, bzw. der _ wird bei mir gar automatisch hingeschrieben, wenn ich die Shift-Taste drücke.
    Die Einsortierung ist doch perfekt, dann sind die Variablen schön beeinander. Wenn ich eine Membervariable suche, dann schaue ich gleich bei den m_ nach. Alles wunderschön gruppiert.
    Das es das Lesen behindert halte ich für recht übertrieben. Man gewöhnt sich schnell dran.

    Alles in allem sind es keine wirklichen Nachteile, sondern subjektiv empfundene Punkte. Es kommt ganz auf die Sichtweise an, von daher ist es eigentlich egal, was man verwendet.

    Shade Of Mine schrieb:

    Keine moderne Sprache hat so eine polnische Notation. Warum sollte man sie in C++ haben?

    1. Es geht nicht um polnische Notation.
    2. Weil alle A sagen ist A auch gut -> Keine Argumentation

    Grüssli



  • Dravere schrieb:

    Könntet ihr das bitte präzisieren, würde mich wunder nehmen. Schreibt ihr Model Klassen ohne Setter? Muss man immer neue Objekte erstellen, wenn man eine Variable anpassen möchte? Ich habe so meine liebe Mühe zu glauben, dass ihr "selten" Setter verwendet. Erst recht, dass ihr goto mehr einsetzt als Setter-Funktionen.

    Keine Ahnung, ich schaue hier gerade durch ein paar Projekte - die setter kann ich an 2 Haenden abzaehlen glaube ich. Diese Zuweisungen finden nahezu immer in den Konstruktoren statt.

    Aber um ehrlich zu sein, selbst in den Faellen wo es setter gibt, sehe ich keinen wirklichen Nachteil an this->

    In Java/C# habe ich zB viele Konstruktoren die so aussehen:

    public XmlResponse(string id, Version version) {
                this.id = id;
                this.version = version;
    
                result = ResultType.RESULT_OK;
            }
    

    PS:
    natuerlich sind die Punkte nicht gravierend. Ich finde es nur ziemlich lustig dass es diese Diskussion nur in C++ gibt. Alle modernen Sprachen fangen sowas (genauso wie ungarische Notation oder Prefixe vor Klassennamen) garnicht erst an zu diskutieren - dort wird das einfach nicht verwendet.

    Und die Variablen sind in den Klassenbrowsern natuerlich immer zusammen und nie unter den Funktionen verteilt - das ist schon automatisch so 😉


Anmelden zum Antworten