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++

Answer 1

I use "m_" as prefix for normal member variables and "s_" for static member variables. So the scope is directly visible.

Answer 2

I think it's important to distinguish between class variables and local ones (and global ones if really needed). How you do it, is not important - just be consistent.

class Foo
{
  int mMember;
  int member_;
  int _member;
  int m_Member;
};

All styles give you the information you need. As long as you stay with the same style all of the time, no problem. Sometimes other people need to work with your code (e.g. when you create a library, or you work with a community). Then it might be a good idea to stick with the most used style in the C++ community.

Sorry - I can't answer what style that is.

Answer 3

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 4

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 5

I came up with this style independently early in my C++ coding days (late 80s, early 90s) because I encountered several confusing situations in which I had to keep going back to the class header to figure out which variable was really a member variable.

Once I started seeing other people's C++ code that did the same thing I was rather gratified that I had noticed a problem that other people had and that the solution I adopted for myself was something other people also thought of.

It's not frequently useful, but it's fairly innocuous and when it is useful, it's very useful.

This is also why I really hate the m_ style. It's not innocuous, and I think the added ugliness is not worth the benefit.

I do use an S_ prefix for file scope static variables and class static variables that aren't constants. They are sort of like global variables, and I think their use should be signaled loudly.

Answer 6

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_;
};