this pointer?

Originally Posted by medievalelks

Second, if the variable changes later to become, say, a file scope static variable, the name must change or it becomes misleading.

Yes, that is akin to a problem with global variables (as in a name change in general), except that the problem is now localised to member and friend functions, which also means that it is less of a problem, especially with a minimal but complete interface.

Originally Posted by anon

E.g do you feel tempted to use i as the counter for all nested for-loops?

Yes! At least where it is used as an index of an array or some other container.

Originally Posted by medievalelks

For one, I rarely see consistency in how these are applied in any moderately sized project with more than one developer.

That's why companies need naming & coding standards, so things stay consistent.

Originally Posted by medievalelks

Second, if the variable changes later to become, say, a file scope static variable, the name must change or it becomes misleading.

And how often does that situation actually happen?
And when it does, how long does a search & replace take?
You'd need to change it anyways if you're prefixing your member variables with this->

Yes! At least where it is used as an index of an array or some other container.

I would be more tempted with nesting iterators. i, j, and k are ok (except you might get a temptation to increment i in all nested loops) but what should I call the iterators - it, jt and kt?

That's why companies need naming & coding standards, so things stay consistent.

As a hobbyist I have tried using m_ and _ prefix, but since I didn't find them very useful (classes are not that big and I mostly don't write setters/get the temptation to use the same name for arguments/local variables) I couldn't force myself to apply them consistently and dropped them altogether.

Originally Posted by cpjust

That's why companies need naming & coding standards, so things stay consistent.

Right, so a bureacratic layer of pencil pushers can reject projects that "don't conform" to their arbitrary standards. I haven't seen them consistenly followed in over 20 years, and I don't expect I ever will.

Also, if I had a dime for every set of coding standards I've seen that were 90% style guides with almost zero mention of safe, good, sound coding practices, I'd be rich. These "standard enforcers" will happily pass code that isn't exception safe, is nothing more than C with classes, is inefficient, or otherwise poorly designed, but scream at the first function they find that doesn't have a ten-line comment block prefix.

And how often does that situation actually happen?
And when it does, how long does a search & replace take?
You'd need to change it anyways if you're prefixing your member variables with this->

I don't use the this-> prefix, so it's not an issue with me. It doesn't matter how long it takes to fix, it means that if you can never really be sure the variable starting with m_ is a member variable without checking.

Originally Posted by anon

I'm not changing the argument name, I just give it a different name? Would you go out of your way to use the same name for different variables in different scopes? E.g do you feel tempted to use i as the counter for all nested for-loops?

I "go out of my way" to make the name of a variable indicate its purpose. My example was generic. Real situations aren't.

Suppose you are configuring the number of wozzes which should be frobbed. The name "numberOfWozzesToFrob" seems good. If some variable represents such a quantity, I want it to have such a name.

You can be arbitrary and have the argument be called "numWozToFrob" and the member be "numberOfWozzesToFrob" but why did you do it that way? At least develop a rule which tells you what you should do.

For a while, I prefixed argument variables with "a". Then I postfixed them with "P". Then I started prefixing members with "m". I'm not militant about any of this, but I definitely don't see how it's harmful.

Originally Posted by medievalelks

I don't use the this-> prefix, so it's not an issue with me. It doesn't matter how long it takes to fix, it means that if you can never really be sure the variable starting with m_ is a member variable without checking.

Because NOT applying a prefix somehow makes it possible to tell without checking?

You can be arbitrary and have the argument be called "numWozToFrob" and the member be "numberOfWozzesToFrob" but why did you do it that way? At least develop a rule which tells you what you should do.

That might be quite much to ask. Ok, in such cases the member variable shall always be called "count_of..."

Originally Posted by brewbuck

Because NOT applying a prefix somehow makes it possible to tell without checking?

I check either way, so some arbitrary, enforced standard is useless, and in fact wastes time and resources trying to enforce.

And it's exactly because no one can be militant enough about style standards that render them useless. Sooner or later you or someone else won't follow the convention, or it will be changed (new code only, of course), and on and on.

Originally Posted by medievalelks

I check either way, so some arbitrary, enforced standard is useless, and in fact wastes time and resources trying to enforce.

And it's exactly because no one can be militant enough about style standards that render them useless. Sooner or later you or someone else won't follow the convention, or it will be changed (new code only, of course), and on and on.

Coding standards aren't even the topic here... We're talking about how to avoid having to use "this->" while still naming variables meaningful names. Using some prefix on member variables has a pragmatic justification beyond just being mandated by a coding standard.

Originally Posted by brewbuck

Using some prefix on member variables has a pragmatic justification beyond just being mandated by a coding standard.

Until it doesn't.

Originally Posted by medievalelks

Until it doesn't.

You still have provided no example of how it could be harmful.

Originally Posted by medievalelks

I don't use the this-> prefix, so it's not an issue with me. It doesn't matter how long it takes to fix, it means that if you can never really be sure the variable starting with m_ is a member variable without checking.

If you ever work with MY code, you won't have to waste your time checking to see whether a variable is a member variable or not because I ALWAYS use m_ to denote a member variable. You can of course waste your time if you want, but that's all it will ever be.

Would the code be easier to read if everybody uses a completely different coding style (some indenting with tabs, others with 2 spaces, others with 5 spaces... Some prefixing member variables with m_, others postfixing with _ and others not doing anything)?

Originally Posted by brewbuck

You still have provided no example of how it could be harmful.

Sure I have. It is misleading if used inconsistently or incorrectly, which is inevitable on any but the smallest of toy projects. Sooner or later someone will forget, use a different prefix/convention, or change a variable and forget to rename, etc.

And, off-topic or not, it's a resource vacuum when the standards Nazis get involved.

Originally Posted by medievalelks

Sure I have. It is misleading if used inconsistently or incorrectly, which is inevitable on any but the smallest of toy projects. Sooner or later someone will forget, use a different prefix/convention, or change a variable and forget to rename, etc.

And, off-topic or not, it's a resource vacuum when the standards Nazis get involved.

When I worked at a large company that actually had such standards, I never saw anyone forget to use m_ for a member variable. Not for the 5 person QA team nor the 8-10 person Development team. Besides, that's why you make doing code reviews a part of your standards.

Originally Posted by medievalelks

Sure I have. It is misleading if used inconsistently or incorrectly, which is inevitable on any but the smallest of toy projects. Sooner or later someone will forget, use a different prefix/convention, or change a variable and forget to rename, etc.

I still don't grok the argument. It sounds like you're saying that coding standards are dangerous because people might forget to use them. Okay... People also forget to update comments, they rely on undocumented and fragile behavior, they don't validate input, they don't check array bounds before accessing, etc. It seems like the safest practice is to just not write any code at all because somebody might make a mistake.

Suppose there is a coding standard in place that says "Every variable must be initialized at the point of declaration." I suppose you take issue with this as well, because somebody may forget to adhere? And the answer is to deliberately not initialize variables?

That is probably somewhat different since it is a bit more than a style question and has more relevance to code correctness.

And in some cases, probably initializing it to any value is meaningless and the initialization doesn't make the code any more correct:

Code:

int n;
std::cin >> n;
//did user enter 57361 or did input fail?

int n = 0;
std::cin >> n;
//did user enter 0 or did input fail?

int n; //or initialized
if (!(std::cin >> n))
//aha!