Naming convention for params of ctors and setters

Question

For those of you who name you member variables with no special notation like m_foo or foo_, how do you name parameters to your ctors and setters?

Some options I've tried so far...

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

I always go for a Param or Arg suffix but only when disambiguation is necessary.

Obj(int fooArg) : foo(fooArg)

Answer 2

I'm using foo_, it's better than _foo since it won't conflict with implementation specific function names and keywords.

Answer 3

I tend to follow the first letter of the parameter that is being set, and disambiguate with this...

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

For a simple setter, for one variable, it is pretty well clear.

Also, I often do this

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

so I can string things together.

Answer 4

I'm going with

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

in my programs. For copy constructors and operator=, i tend to call it

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

For operators, i'm going with

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

Because those are the left hand side and the right hand side of it.

Answer 5

For classes:

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

For structs:

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

Setter:

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

I'm with litb on the use of lhs and rhs for operator calls.

I use camelCase for class member functions, and names_with_underscores for struct fields and methods.

Answer 6

I used to follow the Microsoft convention of prefixing member variables with m_, like m_foo. At my current company the convention is a trailing underscore for member variables: foo_.

Generally, if you are working by yourself, then use whatever convention you like. If you are working in a team, use whatever the team agrees upon. Overall consistency in a code base is what is important, not the particular convention.

Answer 7

I avoid (by avoid mean never use) underscore as the first character of any identifier. I know its overkill but worth the effort.

Read this: http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier#228797

Though not a rule I limit the use of underscore and prefer camel case to make my variables readable. But that's just a personal preference and I don't mind reading code that uses it.

Additionally I never name parameters the same as my member variables. The compiler will not help you catch the kind of errors this can generate (and this is all about getting the compiler to do the real work so you can do the expressive work the compiler can't do).

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

Number two has problems as a convention, although in your case it could be harmless. A name that has a leading underscore followed by an uppercase character is reserved for the implementation, and all names with leading underscores are reserved in a global context. If you never have class members beginning with uppercase letters (I don't), you're safe with the convention as shown (using _foo only as a function argument), but I dislike naming conventions that skirt anywhere near the limits.

Answer 9

I always do this:

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

I used to play games with appending funny symbols until one time I got hit by this:

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

Can you see the mistake? (Yes, b_ is a private member reference variable). It compiled without a warning. Cost me 3 days of debugging (I was a green programmer then).

Now I always use the same name to avoid typos (and subsequent crashes) like that. There is no ambiguity inside the initialization list. This part of the language was designed just for this case, so take advantage of it.

Answer 10

I name the actual members with trailing underscores, so I do this:

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

The reason is so I can use getter functions without anything like getBar() (bar() is better).

Answer 11

I do it like this:

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

The only trick here is to make sure that the letter following the underscore is lowercase. However, I avoid uppercase in identifier names everywhere, as it is inconsistent with conventions used by the standard library (which uses foo_bar_baz for all identifiers).

Answer 12

I follow the Google C++ Style Guide

Variable names are all lowercase, with underscores between words. Class member variables have trailing underscores. For instance: my_exciting_local_variable, my_exciting_member_variable_.