Is using underscore suffix for members beneficial?

Question

class C {
 private:
  int member_; // here is the underscore I refer to.
}

This underscore is recommended by Google Style Guide and Geosoft's C++ Style Guide.

I understand that there are different opinions and tastes.

I want to ask people who used it or were forced to use it whether they found it beneficial, neutral or harmful for them. And why?

Here is my answer:

I understand ask motivation behind it, but it does not convince me. I tried it and all I got was a little bit of clutter all over the class, but simpler initialization of members in constructor. I haven't encountered situation where underscore helped to differ between private member variable and other variable (except in mentioned initialization).

In that light I consider this style harmful.

Answer 1

Well since no one mentioned it: adding an underscore to member variable allows you to name your getter and setter with the 'conceptual' name of the variable.

ex:

class MyClass
{
   int someMember_;

public:
   int someMember() const { return someMember_; }
   void someMember( int newValue ) { someMember_ = newValue; }
};

not that I use this style though.

Answer 2

This came up in discussion we had where I work but with Java programming. But I think this applies to C++ as well. My answer is that IDE's have a handy function of coloring class member variables. In Eclipse they turn blue. The underscore is superfluous. As another poster put it, "EW, hungarian warts!!". 1980 called and wants it's hungarian notation back.

Answer 3

I agree with you that the underscore variable suffix is not the ideal coding style, and that adding a little complexity into the constructor is better than adding more complexity throughout the entire class.

The other day, I took a look at one of my old Java projects where I had applied the underscore suffix to variable names, and I found that it did make reading the code more difficult. It wasn't too hard to get used to, but I found it to be slightly distracting without adding any real benefit.

Answer 4

If you need this underscore in order to tell class members from other variables, you probably have too large member functions to instantly see what's a variable/parameter.

I still like it because it often simplifies member function parameter naming:

class person
{
public:
  person(const std::string& first_name, const std::string& last_name)
    : first_name_(first_name), last_name_(last_name) {}

  // .......

private:
  std::string first_name_;
  std::string last_name_;
};

Answer 5

We follow possibility.com's C++ coding standard, which says to prefix member variables with an 'm', but I've also done some work under Google's style guide.

Like you say, it's not strictly necessary, especially if you have an IDE that assigns different syntax highlighting to member variables. However, I think that some kind of consistent naming scheme, to let you tell at a glance whether or not a variable is a member variable, is very worthwhile:

• Simplified parameter naming, as in sbi's answer, is one benefit.
• A consistent coding style is important, regardless of which style you pick. Ideally, everyone on the team would use the same coding style, so that you can't tell at a glance who wrote a given section of code. This helps helps when bringing new developers onto the team and with agile practices such as no code ownership and is even more important with open source projects that may attract a variety of contributions.
• Most importantly, readability can greatly benefit from having all of the code follow a fairly strict style that makes clear the types of identifiers like this. The difference between being able to tell at a glance that a variable is a member and being able to tell from looking at local variables' declarations may be small, but following a good coding standard will make numerous small differences like this throughout a body of code, and it can make a huge difference in how easy the code is to follow and how easy it is to get started in an unfamiliar section of code.

(You mentioned that you gave this style a try, but if it was only for a part of code and only for code that you were already familiar with, then it's harder to see the readability benefit that following a coding style like this for the entire codebase can bring.)

All of this is in my experience, your mileage may vary, etc.

Answer 6

there is one more "style" which suggests declaring class members as below:

class Foo{
    int m_value;
public:
     //...
};

i found it usable. but it is just my point of view.