Re: Why start variable names with _?
Quote:
Originally Posted by
TheGreatCthulhu
I personally tend to use m_ out of habit, and also because variables starting with _ just "pokes" my eyes.
I definitely do share this feeling. :)
And just to contribute my own $.02...
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 [...]
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:
[...] (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.
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. :)
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).
Re: Why start variable names with _?
Quote:
Originally Posted by monarch_dodra
I have been using for the past 6 months:
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 Eri523
Personally, I use m_ for class members and s_ for statics, together with hungarian notation. I experiented 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.)
:( I'm allergic to Hungarian notation, except for mild forms of Apps Hungarian.
Re: Why start variable names with _?
Quote:
Originally Posted by
laserlight
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?
:( I'm allergic to Hungarian notation, except for mild forms of Apps Hungarian.
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).
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);
Code:
std::vector<int> a_vector;
When I have local variables with explicit names though, I don't prefix with a_:
Code:
std::string tommy = "Tommy"
If find the problem with Hungarian is that it was invented for C, and then leaked into C++.
Re: Why start variable names with _?
Quote:
Originally Posted by monarch_dodra
If your object is a string and nothing more, then why not call it a string?
Yeah, I can see where you are coming from especially with generic code. That said, in your specific first example, why not:
Code:
void to_upper_case(const string& subject, string& result);
Re: Why start variable names with _?
Quote:
Originally Posted by
laserlight
Yeah, I can see where you are coming from especially with generic code. That said, in your specific first example, why not:
Code:
void to_upper_case(const string& subject, string& result);
Well, mostly because I was trying to illustrate my convention :D
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:
Code:
void to_upper_case(const string& i_, string& o_);
Just sayin'... :p
Re: Why start variable names with _?
Quote:
Originally Posted by
monarch_dodra
If your object is a string and nothing more, then why not call it a string?
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.
Re: Why start variable names with _?
Quote:
Originally Posted by
superbonzo
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.
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.
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).
