[C++] Which prefix do you use for member variables?

Started by
22 comments, last by freeworld 12 years, 7 months ago

Why the hell would anyone do this-> unless they had to?


There maybe a big debate and argument, or flame war on this.
But here is three reasons why I prefix this->

1,

class A {
public:
void print(std::string message);
void useIt() {
this->print("what"); // safe

printf("what"); // should call print, but a typo, and compiles and runs OK.
}
};


2,

class A {
public:
void funcA(int someValue) {
someValue *= 2;
this->myAnotherValue = someValue;
}

void funcB(int someValue) {
someValue *= 2;
myAnotherValue = someValue;
}
}


When reading the code, for funcB, I need another 1 or 2 seconds to think "oh, myAnotherValue is member, someValue is parameter, etc". For funcA, I don't need the 1 or 2 seconds. And for funcB I maybe not know if myAnotherValue is a member, a global, or a magic macro, if it's third party code.
OK, typing this-> may need 1 second, but I only need to type once, and will read many time.

3, Sometime it's forced to use this->. Such like value assignment with same name, in some templates. then why not just keep consistent.

https://www.kbasm.com -- My personal website

https://github.com/wqking/eventpp  eventpp -- C++ library for event dispatcher and callback list

https://github.com/cpgf/cpgf  cpgf library -- free C++ open source library for reflection, serialization, script binding, callbacks, and meta data for OpenGL Box2D, SFML and Irrlicht.

Advertisement

Why the hell would anyone do this-> unless they had to?


When I saw this all over the place in a current project my first thought was people are plain lazy and heavily overuse the IDEs autocomplete feature. Apparently this is more common than I thought, but personally I find it adding way too much "noise" to the code (especially when its formatted like people are developing on a calculator display).

Apart from that, I'm using what was mentioned above. PrivateMember_, publicMember (while you can argue that there shouldn't be any public members in the first place, any kind of membership decorator would look just plain wrong on it..
f@dzhttp://festini.device-zero.de
this-> is advantageous in languages that make it mandatory because it enforces member access at compiler level. It's clear, it's unambiguous, it avoids subtle bugs. Unlike m_ which means absolutely nothing, enforces nothing, and triggers nothing at compile time. And there's nothing wrong with being lazy and liking autocomplete lists - it frees up some of your time for use on the more productive stuff, after all. Grinding out boilerplate code by hand doesn't make you a hero after all, it just means that you've spent a lot of time that may have been better spent doing something else.

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.


Poll rhymes with troll.


I never thought of that... hmmm, food for thought.


...but do we ever actually have polls on this site that are anything other than invitations to silly, argument threads? I really don't see the point in the poll functionality on the new site.


agreed

I tend not to prefix any of my variables, if you can't understand what it is from the name, then it was named it wrong. The only prefixing I do, is putting an underscore before function aurguments. Mainly out of old habit, to help discern between member variables that are very similar in name and the variables that were passed in. It very rare that it is useful, but it used to be with alot of other bad habits I've gotten rid of over time.
[ dev journal ]
[ current projects' videos ]
[ Zolo Project ]
I'm not mean, I just like to get to the point.

This topic is closed to new replies.

Advertisement