If you want to get intellisense to work then prefixing your member variables with "m" is much better than "this->".
Well, on my IDE, intellisense waits a full second or two to kick in when typing, but kicks in instantly when dereferencing a pointer, so I get to the intellisense faster. *shrugs*
I admit it is rather silly, but I figured I'd throw out one reason why someone such as myself might use it. It's 'silly', but not 'harmful'.
All you're doing is making more work for yourself and littering your code with useless "this->".
I'm not sure why you think it is 'littering' and 'useless'. It serves the same use as the 'my' prefix. Is the 'my' prefix littering also? Is std:: also littering and useless? I mean, after all, we could just have all C++ functions and classes be called std_string, or win32_CreateWindow. But that's littering too. But it's littering that serves a purpose: distinguishing names in one group from another.
You're not making it any safer from error... you can still forget to write this->
Granted. But it's a habit I chose to adopt, and I almost never forget it, just because it's second nature now. When I want a class variable, I type 'this->'. When I want a standard library class, I type 'std::'. And I very rarely forget to type 'std::'.
and now you're using the wrong variable, because you have no naming difference between local and members.
That's assuming my code even has with places where I overshadow one variable name with an identically named variable in a nested scope. Which I believe is poor practice and so I don't do that. The only place I ever have two variables accessible in the same scope to share the same name is the parameters of class constructors with initializer lists, because they mentally are the same variable, even if they technically aren't.
MyClass::MyClass(int memberVariable) : memberVariable(memberVariable)
By prefixing the members you reduce this possible error because now you have much fewer places where you could screw up... you only have one declaration of the member variable in the class, versus multiple usage of it everywhere else.
Aside from uses outside of the class entirely (and why should the class care about the implementation of the rest of the program, or vise-versa?), no variable within the class (local, global, or otherwise) shares the same variable name as a class' member-variable. That would be inviting errors. I don't need to explicitly protect from errors I'm not exposed to.
All you're doing is making more work for yourself
...
It doesnt matter to me, though, feel free to spend your time typing all the redundant code you want.
In my project currently are (project-wide search:
std:: (x3500)
this-> (x5332)
if(...) (x2169)
for(...) (x373)
// (x33384) <- Lots of unnecessary typing.
/* (x339)
When I'm thinking about code, whether my fingers are typing or not doesn't particularly matter. My typing speed really isn't the bottleneck, so I don't need to optimize for it.
What personally is the bottleneck for me is how fast I can think of what to type, how fast I can isolate bugs, how fast my code compiles (currently too slow - creates undesired interrupts in my workflow).
If I spend extra time typing 'this->' it's a reflex action done without thought. It's not using any resource that would be otherwise occupied. So I'm actually not wasting actual 'time', because it's almost always auto-piloted while I'm using the time to think.
Another point of optimization is how fast I can understand what's going on, when looking at code I've previously written months ago. This is my 'scan speed' - glancing over a piece of code, without tripping up on mental jars from unusual code usage, how fast can I read, process, and discard the information?
this-> actually helps in that category, since (once used consistently, and once familiar with the style) it's easier to parse it mentally as its own token.
variable = 357;
meow = myMeow;
marshmellowsAndCreme = "my text!"
myMongooseArmy = meow * myMarmoset;
vs:
variable = 357;
meow = this->Meow;
marshmellowsAndCreme = "my text!"
this->MongooseArmy = meow * this->Marmoset;
It's such a minor issue that I really don't think one is better than the other - nor do I advocate my way. I do strongly believe and advocate that consistency with whatever styles one uses is very important, and often more important than the choice of style itself.
I've actually considered switching to the 'my' prefix style, but found it such a non-issue that I've pushed it off to a far distant date several projects from now when I have a clean codebase (important changes to style I implement immediately, refactoring existing places in my code - unimportant style-changes can wait for a new empty project). I just don't find the pros and cons to be such as to require a change of style.
I'll try it sometime, and see if I like it better, but I don't feel any rush or see any need.
But perhaps I'm optimizing the wrong areas. Maybe I need to optimize my life-span by not spending over an hour writing a post debating something even less relevant than brace-styles. Well, too late now!