C++ Member Variables

Question

Consider the following class:

class A
{
  A();
  int number;
  void setNumber(int number);
};

You could implement 'setNumber' in 3 ways:

Method 1: Use the 'this' pointer.

void A::setNumber(int number)
{
  this->number = number;
}

Method 2: Use the scope resolution operator.

void A::setNumber(int number)
{
  A::number = number;
}

Method 3: Instead, denote all member variables with 'm' or '_' (this is my preferred method).

void A::setNumber(int number)
{
  mNumber = number;
}

Is this just personal preference, or is there a benefit to choosing a particular method?

Solution 1

This is mostly a personal preference, but let me share my perspective on the issue from inside a company where many small games are being made simultaneously (and so there are many coding styles being used around me).

This link has several good, related, answers: Why use prefixes on member variables in C++ classes

Your option 1:

void A::setNumber(int number)
{
  this->number = number;
}

First off, many programmers tend to find this cumbersome, to continually type out the ' this-> '. Second, and more importantly, if any of your variables shares a name with a parameter or a local variable, a find-replace designed to say, change the name of 'number' might affect the member variables located in the find-replace scope as well.

Your option 2:

void A::setNumber(int number)
{
  A::number = number;
}

The problem I've run into with this, is that in large classes, or classes with large functions (where you cannot see the function or the class is named unexpectedly), the formatting of A::(thing) looks very much like accessing a part of a namespace, and so can be misleading. The other issue is the same as #2 from the previous option, if your names are similar to any variables you're using there can be unexpected confusion sometimes.

Your option 3:

void A::setNumber(int number) 
{
  mNumber = number;
}

This is the best of those three presented options. By creating (and holding to!) a syntax that involves a clear and meaningful prefix, you not only create a unique name that a local (or global) variable won't share, but you make it immediately clear where that variable is declared, regardless of the context you find it in. I've seen it done both like this ' mVariable ' and like this 'm_variable' and it mostly depends upon if you prefer underscores to uppercase concatenation. In addition, if your style tends to add things like ' p 's on for pointers, or ' g 's on for globals, this style will mesh well and be expected by readers.

Solution 2

It is a matter of style, thus personal preference, or a preference of the team you are working with or the boss of the team you are working with.

Solution 3

Option 4:

void A::setNumber(int n)
{
  number = n;
}

Why is the benefit of using the same name for a member and a parameter. No good can come of this. Sure, it's clear now, but when your methods get large, and the prototype doesn't fit in the screen anymore, and there's some other developer writing code, he may forget to qualify the member.

Solution 4

its all personal preference

but here is a good discussion on it at a high non language level

https://stackoverflow.com/questions/381098/what-naming-convention-do-you-use-for-member-variables

Solution 5

I would say the choice between Method 1 and Method 3 is a matter of personal or organizational style.

Method 2 is an inferior because Class::member typically denotes a static member variable, and thus would cause confusion if used to disambiguate between a parameter and member variable.

View more solutions

Comments

[Evan Mulawski]

@R.MartinhoFernandes: It's an example, for simplicity.

[Kerrek SB]

The third one. There's no need to ever use this-> in C++ except if you are dealing with a templated base class. Leave the verbose noise to Java and PHP.

[Jerry Coffin]

Method 4: eliminate setters in favor of providing higher-level operations (though, of course, this isn't always practical).

[Julian]

Thanks for all of the great responses everyone! I wish I could accept all of your answers. @JerryCoffin: Definitely makes sense, but, as you mentioned, this isn't always practical.

[Sampson]

As written, this is not an answer.

[Luchian Grigore]

@JonathanSampson I'm saying he should prefer neither.

[Luchian Grigore]

@EvanMulawski Method 3 is in hungarian notation. :)

[Philipp]

This has the disadvantage that you cannot mechanically translate between parameter and member names and quickly run out of abbreviations.

[Carl]

Vlad is right. Just make sure that no matter which style you end up using, you don't get religious about it. It's just style, nothing else. The key is you need to understand what the code is doing regardless of the style its written in, so don't overthink it :) Just follow the surrounding code unless you have a good technical reason not to.

[Big Temp]

Aaand the link is dead