Poll: What to name constructor variables

Started by
47 comments, last by pex22 19 years, 7 months ago
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.
Advertisement
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.
"We should have a great fewer disputes in the world if words were taken for what they are, the signs of our ideas only, and not for things themselves." - John Locke
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_?
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;}
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.
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.
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.
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.
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.
John BoltonLocomotive Games (THQ)Current Project: Destroy All Humans (Wii). IN STORES NOW!
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;}

This topic is closed to new replies.

Advertisement