Sign in to follow this  

Poll: What to name constructor variables

This topic is 4834 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello, what do you people name your constructor variables? By that I mean if we have a class Circle with members called "x", "y", and "radius", what would you name the parameters in the constructor? The way I've been doing it so far is prefixing the names of the member variables with an _underscore, making stuff look like this:
class Circle
{
public:

  Circle(float _x, float _y, float _radius)
  {
     //ignore the lack of range checking
     x = _x;
     y = _y;
     radius = _radius;
  }

private:

  float x, y, radius;
}


It's worked fine for me so far but I was wondering if there were any better naming schemes.

Share this post


Link to post
Share on other sites
The typical way is to actually prefix member variables, not the arguments to functions.

class Circle
{
public:

Circle(float x, float y, float radius)
{
//ignore the lack of range checking
m_x = x;
m_y = y;
m_radius = radius;
}

private:

float m_x, m_y, m_radius;
}



One benefit of this method is so that any tooltip text, auto-documentation, etc., that describe functions will list the parameters exactly as how one would expect them to be listed, "x", "y", "radius", not with odd prefixes, or as abbreviations, etc. What the class looks like on the outside is more important than what it looks like on the inside.

Share this post


Link to post
Share on other sites
Hmm.. I've seen that before but I've avoided it because I never felt it was necessary. Your point about the interface cleanliness over the implementation is new to me but certainly makes sense though. Thanks, I'll probably adopt the m_.

Along these lines, do you also prefix global variables with g_?

Share this post


Link to post
Share on other sites
To be honest, I've always preferred:


class Circle
{
public:

Circle(float x, float y, float radius)
{
//ignore the lack of range checking
this->x = x;
this->y = y;
this->radius = radius;
}

private:

float x, y, radius;
}

Share this post


Link to post
Share on other sites
I generally prefix the parameters with in*. But then again I make nearly everything public [yes, yes poor form; I've heard it before], so prefixing the internals is less desirable.

Share this post


Link to post
Share on other sites
Quote:
Original post by hellz
To be honest, I've always preferred:

*** Source Snippet Removed ***


Hey, that's pretty neat! I think I will adopt the m_ prefix though. Thanks for your reply anyway :P

EDIT: I just remembered that you can't say "this" in the constructor's initializer list! Still nifty though.

Share this post


Link to post
Share on other sites
Thanks. [smile] Don't get me wrong, I really do like the idea of prefixing everything, but I often find that using underscores in code, just makes it an absolute pain to type. Perhaps it's not an issue to most, but my hands/arms already feel as though they're suffering from mild RSI, so I'm trying not to make it worse. [smile]

I've seen people use this sort of style for C#:


class Circle
{
public:

Circle(float x, float y, float radius)
{
//ignore the lack of range checking
mX = x;
mY = y;
mRadius = radius;
}

private:

float mX, mY, mRadius;
}



I don't mind that so much, but still prefer the other way.

Share this post


Link to post
Share on other sites
I prefix member variables with m_, globals with g_ and static members with s_. I strongly dislike code where member variables aren't prefixed at all, its difficult to see is a variable is a member varialbe or a local variable. Likewise for globals.

EDIT: I only do that for private and protected variables.

Share this post


Link to post
Share on other sites
I do almost the same as Evil Steve. I find it very helpful to be able to know the scope of variables when reading the code. "g_" is global. "m_" is member. "s_" is local to a file. I haven't decided how to prefix variables declared in a namespace.

Share this post


Link to post
Share on other sites
C'mon, guys. Remember your C++. It's all about initializer lists.


class Circle
{
public:
Circle(float x, float y, float radius) :
x(x), y(y), radius(radius)
{
}

private:
float x, y, radius;
}

Share this post


Link to post
Share on other sites
Quote:
Original post by JohnBolton
I haven't decided how to prefix variables declared in a namespace.


I'd say n_, but that's quite close to m_. How about ns_? Should be clear enough.

Share this post


Link to post
Share on other sites
Quote:
Original post by JohnBolton
I haven't decided how to prefix variables declared in a namespace.
With the namespace name followed by the scope resolution operator?

Share this post


Link to post
Share on other sites
Quote:
Original post by Russell
In C++ you shouldn't prefix anything with an underscore (ex. _var). Postfixing an underscore is fine (ex. var_).

Prefixing something with only an underscore implies that its compiler specific (for those who were going to say "why not" :P), but so long as its clear, I don't see a paroblem with it. For something as simple as a constructor, it should be fine.#

Quote:
Original post by Sneftel
Quote:
Original post by JohnBolton
I haven't decided how to prefix variables declared in a namespace.
With the namespace name followed by the scope resolution operator?

Rofl

Share this post


Link to post
Share on other sites
Quote:
Original post by Machinoid
So, what about prefixing private methods?

m_DoSomething( radius );

I don't tend to do that, because to me the m_ prefix implies a variable. I don't find that a prefix is nessecary for functions, although I'm sure others probably use prefixes.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
C'mon, guys. Remember your C++. It's all about initializer lists.

*** Source Snippet Removed ***
Does that actually work? With the " : x(x), y(y)" initializer list thing going on? If so, yet another thing I've learned from this wonderful board...

Share this post


Link to post
Share on other sites
m_ is a bit of Hungarian notation. There is a very divisive running argument regarding Hungarian notation and its relative merits and boons.

I prefer undecorated arguments so that autodocumenting programs can publish the parameter names without arg_ or in_ or any other decoration in the documentation.

Apart from that, please make your variable names pronouncable. This makes globbing them in my head easier and therefore I can retain more of the code in my head. I haven't seen this one published anywhere -it is my own invention and I am quite pleased with it. It is also why I am a naysayer to rote adherence to Hungarian.

Share this post


Link to post
Share on other sites
Quote:
Original post by Evil Steve
Quote:
Original post by Russell
In C++ you shouldn't prefix anything with an underscore (ex. _var). Postfixing an underscore is fine (ex. var_).

Prefixing something with only an underscore implies that its compiler specific (for those who were going to say "why not" :P), but so long as its clear, I don't see a paroblem with it. For something as simple as a constructor, it should be fine.

Specifically, any name prefixed with an underscore is reserved for the implementation. As far as I understand, this means that your compiler may, for instance, use any name beginning with an underscore for, say, some horrible macro—though I am no expert. For this reason (or for fear of this being true), I avoid prefixing anything with underscores.

Share this post


Link to post
Share on other sites
Quote:
Original post by Agony
Does that actually work? With the " : x(x), y(y)" initializer list thing going on?
Yes it does. Since initializer lists only initialize member variables, those are the only variables in scope when resolving the target to be initialized. However, the argument to each constructor follows normal resolution rules, so local variables take precedence over member variables.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
Quote:
Original post by Agony
Does that actually work? With the " : x(x), y(y)" initializer list thing going on?
Yes it does. Since initializer lists only initialize member variables, those are the only variables in scope when resolving the target to be initialized. However, the argument to each constructor follows normal resolution rules, so local variables take precedence over member variables.
I'll add that to the list of things I wish I had known months ago. Thank you.

Share this post


Link to post
Share on other sites
At the place I work, the coding standard requires prefixing private member variables with m_ as well as prefixing parameter names with p_.

Of course, it also requires a modified hungarian notation, so you can probably safely ignore it.

In my own code, I use m_ for all private variables, but I generally avoid the p_ part.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
Quote:
Original post by Agony
Does that actually work? With the " : x(x), y(y)" initializer list thing going on?
Yes it does. Since initializer lists only initialize member variables, those are the only variables in scope when resolving the target to be initialized. However, the argument to each constructor follows normal resolution rules, so local variables take precedence over member variables.


Wowow. 1337.

Share this post


Link to post
Share on other sites
Quote:
Original post by Evil Steve
Prefixing something with only an underscore implies that its compiler specific (for those who were going to say "why not" :P), but so long as its clear, I don't see a paroblem with it. For something as simple as a constructor, it should be fine.


I believe the actual rule is that any name in the global namespace with a leading underscore followed by a capital letter is reserved for the compiler. In addition, any name containing two consecutive underscores anywhere in the name is reserved for the compiler.

It should be fine if you want to rely on that standard holding up 100% of the time, but we live in a real world, not a theoretical one. If your options are (A) don't prefix an underscore to anything and never have any problems with this issue, or (B) prefix things but be careful and rely on your own discipline and that the compiler implementors didn't make any mistakes, I see no benefit of choosing B. I have heard that some compilers don't handle this correctly, so there is a real downside to B (however small). Any upside?

Share this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
Quote:
Original post by Agony
Does that actually work? With the " : x(x), y(y)" initializer list thing going on?
Yes it does. Since initializer lists only initialize member variables, those are the only variables in scope when resolving the target to be initialized. However, the argument to each constructor follows normal resolution rules, so local variables take precedence over member variables.


Every time I think I know something about C++ I learn something new O_o (thanks for the explanation)

Also, I wouldn't really classify the m_ and g_ as hungarian notation; the m_/g_ signify scope, not variable type.

Share this post


Link to post
Share on other sites

This topic is 4834 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this