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

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

Answer 2

To me the benefit of this style of decorating member variables is it works well with auto complete functionality of text editors. Having a prefix decoration requires you to type more characters before a solid guess on what you mean can be made.

Answer 3

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 4

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 5

This is basically a religious argument so you're never going to reach a consensus on this style. FWIW, I use this style for my member variables for reasons already stated by others, e.g.:

class Foo
{
public:
  Foo(std::string name, int age) :
    name_(name),
    age_(age)
  {
  }

  std::string name() const { return name_; }
  void name(const std::string& name) { name_ = name; }

  int age() const { return age_; }
  void age(int age) { age_ = age; }
private:
  std::string name_;
  int age_;
};

Just adopt something you're happy with and stick with it.

Answer 6

I agree with Tobias that there's a benefit to some convention -- whatever it may be -- to highlighting class variables. On the other hand, I invariably find that such conventions make the code "flow" less well. It's just easier to read "totalPrice = productPrice + salesTax" then "m_totalPrice = l_productPrice + l_salesTax" or whatever.

In the end, I prefer to just leave all the field names undecorated, and have few enough class variables that keeping track of them is not a problem. In constructors and setters, I put a prefix or suffix on the parameter, or in Java I typically distinguish the class variable with "this.", like:

public Foo(int bar)
{
  this.bar=bar;
}

(Can you do that in C++? It's been so long I don't remember.)