Printable View
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.
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". ;):)Quote:
Originally Posted by 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?
We always have threads about this.Quote:
Originally Posted by ninja9578
Technically that's only true in the global namespace. In general, _(capital letter) is reserved everywhere, and double __ is reserved everywhere.Quote:
Originally Posted by ninja9578
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.
However, if you copy Lindley, don't use double trailing underscores, because the rule concerning double (consecutive) underscores applies regardless of their position.Quote:
Originally Posted by Lindley
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.
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).Quote:
Originally Posted by S_M_A
Viggy
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.
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.
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.
True.
"Most things are members" :confused: 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.Quote:
Originally Posted by S_M_A
----
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:
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.Code:m_ : member variable;
i_ : function input variable;
o_: function output variable;
g_ : global/static variable
a_ : stack variable
I definitely do share this feeling. :)Quote:
Originally Posted by TheGreatCthulhu
And just to contribute my own $.02...
IDEs may do, online platforms where code is published, like CG, for instance, AFAICT usually don't. Neither do books, at least as long as they're made out of ordinary paper.Quote:
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 [...]
Though distinguishing between locals (and parameters) and members of the same name perhaps IMO is the only legitimate reason to explicitly dereference this, I still simply don't like it. Simply looks too javaish to me and also seems to be somewhat common in C#. Personal taste, admittedly. :)Quote:
[...] (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.
Personally, I use m_ for class members and s_ for statics, together with hungarian notation. I experimented with decorating parameters but dropped that since I found it too cluttering together with hungarian notation. For locals and parameters I use hungarian notation without any further decoration except when they're static. (And except for some really obvious things like for loop variables which often simply are named i or something. Some sort of "hungarian only" notation.)
And for completeness, I use Pascal case for methods (and .NET properties, at least most of the time).
The o_ prefix for a function's out parameter sounds interesting to me. However, is there really a point for the i_ and a_ prefixes when they are for local variables that should be easily determined by the declaration context?Quote:
Originally Posted by monarch_dodra
:( I'm allergic to Hungarian notation, except for mild forms of Apps Hungarian.Quote:
Originally Posted by Eri523
The use of the _i is mostly for symmetry with _o. Also, it is to give the option of writing _o or _io (eg pure output, or input/output).Quote:
Originally Posted by laserlight
What I have found that is also helpful with a_ (and _i), is that it allows to name your variable the same as your class. This avoids having to think too hard about the names, and I find it actually makes the naming better. If your object is a string and nothing more, then why not call it a string?
Code:void to_upper_case(const string& i_string, string& o_string);
When I have local variables with explicit names though, I don't prefix with a_:Code:std::vector<int> a_vector;
If find the problem with Hungarian is that it was invented for C, and then leaked into C++.Code:std::string tommy = "Tommy"
Yeah, I can see where you are coming from especially with generic code. That said, in your specific first example, why not:Quote:
Originally Posted by monarch_dodra
Code:void to_upper_case(const string& subject, string& result);
Well, mostly because I was trying to illustrate my convention :DQuote:
Originally Posted by laserlight
You should notice though, that with your names, you have basically lost the info that the variables are strings, and only retained their i_ and o_ property. I could mostly trim your example down to my scheme, and write it as:
Just sayin'... :pCode:void to_upper_case(const string& i_, string& o_);
because you're spreading redundant informations already evident from the variable type ... it's like those comments stating the obvious. At best, they serve no purpose; at worst, they make mantainance harder ( in general, what happens if you change the type ? you'll need to change the variable name too ... ). IMHO, the purpose of that function is immediately evident from the function name and signature alone.Quote:
Originally Posted by monarch_dodra
Of course the purpose of the function is obvious, but you still have to give the arguments names. Maybe the "string" suffix is indeed not the best choice (and I will take it into account in the future), but that's the best I could come up with in the 5 seconds I gave myself to chose a variable name.Quote:
Originally Posted by superbonzo
As for the i & o, I have (personally) found that they help. Even if you can ascertain this info from the signature, having the prefix means I don't have to re-read the signature to remember which is which.
EDIT: From signature alone though, it is not possible to distinguish an input-output (eg, a vector you append to), from an output only (a vector you clear before writing to).