Here's what the C++ Standard says (17.4.3.1.2): "Each name that contains a double underscore (_ _) or begins with an underscore followed by an uppercase letter is reserved to the implementation" and "Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace."
|
http://pkisensee.spaces.live.com/blog/cns!3C84486A9D832EB7!246.entry
They are "reserved," but not "restricted," meaning you can use them if you like. The danger (as indicated in the link) is that your particular compiler may just happen to use it as part of its "implementation," and you'll get a bug that'll keep you up late for weeks.
I personally tend to follow a convention used in Delphi programming and that is to prefix private data with the letter
F, as:
1 2 3 4
|
private:
int f_age;
std::string f_name;
...
|
(BTW, IDislikeClumpedUpVariableNames.)
I've also seen stuff beginning with a lowercase
M, as in:
1 2 3 4
|
private:
int mAge;
std::string mName;
...
|
Personally, I think that a leading underscore looks funny and hokey, so I avoid it whenever possible (but that doesn't mean I haven't been known to use them in weak moments).
A better convention would be to set your
arguments to begin with underscores (or in the Delphi convention, the letter
A):
1 2 3 4 5
|
void setEars( std::string _length, std::string _type )
{
earLength = _length;
earType = _type;
}
|
or
1 2 3 4 5
|
void setEars( std::string aLength, std::string aType )
{
earLength = aLength;
earType = aType;
}
|
This is perfectly safe and acceptable, since arguments are temporary variables in a local scope... so long as you don't do some magic that will cause your compiler to invade the local scope with "its" stuff (using templates and the like).
Also personally, I think it is not much grief to simply use the same names:
1 2 3 4 5
|
void setEars( std::string earLength, std::string earType )
{
this->earLength = earLength;
this->earType = earType;
}
|
Such usage avoids all ambiguity and has the benefit of unadorned names everywhere. The only place it is a potential clash is in the
setEars() method, and it wasn't even a problem.
/end dump