Namenskonvention für Parameter von Ctors und Setter

Question

Für diejenigen unter Ihnen, die Sie Member-Variablen ohne besondere Notation wie m_foo oder foo_ nennen, wie benennen Sie Parameter zu Ihren Ctors und Setter?

Einige Optionen, die ich bisher ausprobiert habe ...

Obj(int foo) : foo(foo) { } 
void set_foo(int foo) { this->foo = foo; } 

Obj(int _foo) : foo(_foo) { } 
void set_foo(int _foo) { foo = _foo; } 

Obj(int a_foo) : foo(a_foo) { } // a for "argument" 
void set_foo(int a_foo) { foo = a_foo; } 

Obj(int init_foo) : foo(init_foo) { } 
void set_foo(int new_foo) { foo = new_foo; } 

Answer 1

Ich gehe immer für eine Param oder Suffix Arg aber nur, wenn Begriffsklärung notwendig.

Obj(int fooArg) : foo(fooArg) 

Answer 2

ich foo_ bin mit, dann ist es besser als _foo, da sie nicht mit der Implementierung spezifischen Funktionsnamen und Schlüsselwörter in Konflikt stehen.

Answer 3

Ich neige dazu, den ersten Buchstaben des Parameters zu folgen, die festgelegt wird, und Mehrdeutigkeiten mit diesem ...

void setFoo(int f) { foo = f; } 

Für eine einfache Setter, für eine Variable, ist es ziemlich gut klar.

Auch ich oft diese

int setFoo(const int f) { foo = f; } 

so kann ich String Dinge zusammen.

Answer 4

Ich bin mit

Obj(int foo) : mFoo(foo) { } 
void setFoo(int foo) { mFoo = foo; } 

in meinen Programmen gehen. Für Kopierkonstruktoren und Operator =, neige ich dazu, es für die Betreiber

Obj(Obj const& that):mFoo(that.mFoo) { } 

zu nennen, werde ich mit

Obj operator+(Obj const& lhs, Obj const& rhs) { ... } 

Weil diejenigen, die l inks h und s ide sind und die r ight h und s ide davon.

Answer 5

Für die Klassen:

Obj(int foo) : _foo(foo) {}; 

Für structs:

obj_t(int foo_) : foo(foo_) {}; 

Setter:

Obj.setFoo(int foo) { _foo = foo; } 

Ich bin mit litb über die Verwendung von lhs und rhs für Betreiber Anrufe.

Ich verwende camelCase für Klassenmitglieder Funktionen und names_with_underscores für Struktur Felder und Methoden.

Answer 6

Ich folgte der Microsoft-Konvention der Präfixing Member-Variablen mit m_, wie m_foo. Bei meiner jetzigen Firma ist die Konvention ein Hinterstrich für Membervariablen: foo_.

Im Allgemeinen, wenn Sie selbst arbeiten, dann verwenden Sie die Konvention, die Sie mögen. Wenn Sie in einem Team arbeiten, verwenden Sie, was auch immer das Team zustimmt. Die Gesamtkonsistenz in einer Codebasis ist wichtig, nicht die bestimmte Konvention.

Answer 7

Ich vermeide (von vermeiden, nie verwenden) Unterstrich als das erste Zeichen eines Bezeichners. Ich kenne seinen Overkill, aber es lohnt sich.

Lesen Sie dazu: What are the rules about using an underscore in a C++ identifier?

Obwohl keine Regel, die ich die Verwendung von Unterstrichen begrenzen und bevorzugen Kamel Fall meine Variablen lesbar zu machen. Aber das ist nur eine persönliche Vorliebe und es macht mir nichts aus, Code zu lesen, der es benutzt.

Zusätzlich benenne ich Parameter nie die gleichen wie meine Member-Variablen. Der Compiler wird Ihnen nicht dabei helfen, die Art von Fehlern zu erkennen, die dadurch entstehen können (und dabei geht es darum, den Compiler dazu zu bringen, die eigentliche Arbeit auszuführen, damit Sie die ausdrucksvolle Arbeit ausführen können, die der Compiler nicht leisten kann).

int X::setWork(int work) 
{ 
    this->work = work; // OK. But more Java like. 

    work = work;  // Compiler won't see that problem. 
} 

int X::setWork(int newWork) 
{ 
    work = newWork; // A bit harder to get wrong. 
} 

Answer 8

Nummer zwei hat Probleme als eine Konvention, obwohl in Ihrem Fall könnte es harmlos sein. Ein Name mit einem führenden Unterstrich gefolgt von einem Großbuchstaben ist für die Implementierung reserviert, und alle Namen mit führenden Unterstrichen sind in einem globalen Kontext reserviert. Wenn Sie niemals Klassenmitglieder haben, die mit Großbuchstaben beginnen (tue ich nicht), sind Sie mit der Konvention wie gezeigt sicher (mit _foo nur als Funktionsargument), aber ich mag keine Namenskonventionen, die irgendwo in der Nähe der Grenzen liegen.

Answer 9

ich immer:

Obj(int foo) : foo(foo) {} 

Ich benutzte Spiele spielen mit Anhängen lustige Symbole, bis eine Zeit, die ich durch diese getroffen wurde:

Obj(Bar& b) : b_(b_) {} 

Können Sie den Fehler sehen? (Ja, b_ ist eine private Referenzvariable für Mitglieder). Es kompiliert ohne Warnung. Kostet mich 3 Tage Debugging (ich war damals ein grüner Programmierer).

Jetzt benutze ich immer den gleichen Namen, um Tippfehler (und nachfolgende Abstürze) zu vermeiden. In der Initialisierungsliste gibt es keine Mehrdeutigkeit. Dieser Teil der Sprache wurde nur für diesen Fall entworfen, also nutzen Sie ihn aus.

Answer 10

Ich nenne die tatsächlichen Mitglieder mit Hinter Unterstrichen, so dass ich dies tun:

Foo(int bar) : bar_(bar) { } 

Der Grund dafür ist, so kann ich Getter Funktionen, ohne etwas wie GetBar() (bar() ist besser) verwenden.

Answer 11

Ich mache es wie folgt aus:

obj(int foo) : _foo(foo) { } 
int foo() const { return _foo; } 
void foo(int value) { _foo = value; } 

Der einzige Trick, um sicherzustellen, dass der Buchstabe nach dem Unterstrich Klein ist. Ich vermeide jedoch Großbuchstaben in Bezeichner-Namen überall, da es nicht mit Konventionen übereinstimmt, die von der Standardbibliothek verwendet werden (die foo_bar_baz für alle Bezeichner verwendet).

Answer 12

Ich folge die Google C++ Style Guide

Variablennamen klein geschrieben sind, mit Unterstrichen zwischen den Wörtern.Klassenmitgliedsvariablen haben nachgestellte Unterstriche. Zum Beispiel: my_exciting_local_variable, my_exciting_member_variable_.