Just curious

Just 'm' here, 'g' for the few globals that might pop in (I try to avoid them, obviously) and I add an 's' when either are static. Basically I use prefixes to denote scope, with locals and parameters having no prefix.

Bleh, prefixes.

If the standards of my group dictate them, I'll argue against and then conform. Otherwise they're a waste.

this-> where appropriate because it makes it explicit to anyone reading the code that yes, this is a member.

I despise g_ and m_ primarily on account of the fact that they make autocomplete lists look like a wall of too-similarly-named variables. Combine them with hungarian notation and you may have to jump up to 6 or so characters into the variable name before you get to the meaningful stuff that uniquely identifies it. That's a pretty damn poor signal-to-noise ratio in my book. Only a business manager type who's never actually sat down and written code using this stuff could truly love it.

Personally, I find *very* minimal prefixes like I use to increase "at a glance" readability. prefixes which denote scope provide information that intellisense doesn't, unlike wrongly-used hungarian type prefixes -- though correctly-used, hungarian semantic prefixes actually can increase readability, but I don't use them myself.

Using either scope-based prefixes or proper, semantic Hungarian actually can aid intellisense if used consistently -- pressing 'm' delivers a list of all members that are in scope for example, or 'km' might deliver a list of variables which are measured in kilometers in a semantic Hungarian, as another.


I want to like the idea of using "this->" however its 5 extra (relatively common) keystrokes, and also the compiler will do nothing to enforce consistent usage, and neglecting it can make unintentional aliasing possible (however uncommon).

Basically, if you choose to use prefixes, don't duplicate information that your IDE will already give you with a mouse-over. If your prefixes, whatever they may be, don't add real value to understanding, then they're just wasted keystrokes.

Personally I use no decoration for public member variables, trailing underscore for private, and ban protected.

Also, +this

publics should not be decorated, because they are basically hoisted into the enclosing scope, and no longer "member"s in the sense of having limited scope.

I use no any decoration except some internal namespace (start with _).
But I prefix EACH member access with this-> to indicate it's a member explicitly.
Not only C++, I keep same style in Java and other appropriate language also.