Why start variable names with _?

[SterlingM]

I am looking at some C++ code that has many variables that start with underscores. Why? What's the point? I know in Python its a way to keep them private, but I don't understand why we would do that in C++ when we can just make something private. So can someone please explain what the point of it is? Thanks for any help.

[Lindley]

Style, nothing more. The idea is that the name instantly tells you something about the variable.

Some people start private members with _ (or, more commonly, m_ for "my"). Some people start function parameters with _. It doesn't serve any useful purpose except to the person maintaining the code.

[GCDEF]

Style, nothing more. The idea is that the name instantly tells you something about the variable.

Some people start private members with _ (or, more commonly, m_ for "my"). Some people start function parameters with _. It doesn't serve any useful purpose except to the person maintaining the code.

I start class members with m_, but when I do it, m_ stands for "member".

[ninja9578]

Didn't we recently have a thread about how you are NOT supposed to do that because it should be reserved for library implementation?

[monarch_dodra]

Didn't we recently have a thread about how you are NOT supposed to do that because it should be reserved for library implementation?

We always have threads about this.

[Lindley]

Didn't we recently have a thread about how you are NOT supposed to do that because it should be reserved for library implementation?

Technically that's only true in the global namespace. In general, _(capital letter) is reserved everywhere, and double __ is reserved everywhere.

But yes, in general it's a good idea not to use a leading underscore. In those cases where I do use underscores, I tend to make them trailing rather than leading.

[laserlight]

In those cases where I do use underscores, I tend to make them trailing rather than leading.

However, if you copy Lindley, don't use double trailing underscores, because the rule concerning double (consecutive) underscores applies regardless of their position.

[monarch_dodra]

I used to use _+(lowercase) because while seemingly dangerous, it is legal.

Then one day, I got tired of people saying I couldn't do it, and having to argue with them, and having the same discussion over and over. Now I just go with gcc's convention of m_. Now nobody bothers me anymore, and my code is just as clear.

Now if only people would stop bothering me when I use gotos.

[S_M_A]

I don't use m_ or anything similar anymore. After all, most things should be members anyway so if something should be marked in a special way it's things that are not members.

[MrViggy]

I don't use m_ or anything similar anymore. After all, most things should be members anyway so if something should be marked in a special way it's things that are not members.

I would say that depends. Most of the variables I use are temporary, thus local to the function I'm writing (i.e. not members).

Viggy

[S_M_A]

True but then (in my opinion) the method or section of code where the locals are used should be small enough to not create any doubts on if the vars are members or not.

[TheGreatCthulhu]

The two primary reasons for the (m_/_)-convention are, IMO & IIRC, the need to (1) quickly distinguish private class member variables from local or global variables while reading code, and more importantly, to (2) prevent name collisions when you have member functions with one or more parameters named the same as some of the member variables.

And this convention has as many pros as it has cons.
I personally tend to use m_ out of habit, and also because variables starting with _ just "pokes" my eyes.

However, those arguing against this practice say that (1), most IDE's today will provide ways for you to distinguish member variables from other types of variables, for example, just by hovering your mouse over, and (2) there are comparatively few cases where you need, due to name collisions, to type in the extra "this.", as opposed to typing "m_" or "_" every single time.

As for (2), can't really argue with that, except that some people like all their member variables clumped together when shown in tools like IntelliSense.
As for (1): what if you're reading code snippets, on a forum, for example?

But in the end, it's a matter of personal style and preference.

[S_M_A]

All methods have their pros and cons and I can't say I have a problem with either one. Meaningful names on variables and methods is by far the most important thing for me. If they are camel cased, m_ or follow any other rule doesn't help a thing if they doesn't say anything.

[TheGreatCthulhu]

True.

[monarch_dodra]

I don't use m_ or anything similar anymore. After all, most things should be members anyway so if something should be marked in a special way it's things that are not members.

"Most things are members" What do you develop on? If you have "small function building blocks", I tend to find that 50% of my variables are function arguments actually.

----
IMO, a variable name should be enough to know what the variable is/represents, and I agree with that concept. However, I find that it is always a bit limited at telling you where the variable is from, and what its life cycle is.

For example: list_of_names: Duh, its is an std::list of strings. But is it a member variable? an io argument?

I have been using for the past 6 months:

m_ : member variable;
i_ : function input variable;
o_: function output variable;
g_ : global/static variable
a_ : stack variable

I've found it to very useful in writing code without thinking to hard. I have also found the "acceptance factor" of people reading my code to be quite high.