sa*********@yahoo.com (Sandeep Sharma) wrote:
For many years I have been following the convention of naming all
class attributes with a leading underscore. This enables me to
quickly identify the class attributes when I encounter them in the
source code. Even the GoF book follows this convention, although it's
true that the GoF book is not an authoritative source for coding
guidelines.
Recently a colleague remarked that using a leading underscore is a bad
programming practice that should be avoided at all costs. According
to her this has to do with the fact that the compiler naming mangling
procedure also sticks leading underscores and therefore using
underscores in the source code makes the job of following the
post-processed source code (should there ever be a need) very
difficult.
The point here is to try to convey a certian piece of information, that
the variable in question is a member-variable. I see no reason to use
two characters to convey that information when one will do, so using
underscore + lower case (_variable) or 'm' + upper case (mVariable) both
seem like good options, but combining them into 'm_' seems like a waste.
Having a trailing underscore, (or any sort of trailing character) is
hard to parse for me. Maybe I'm too old school.
But why do we have to convey this particular piece of information? If
the variable is local, then it will be defined right there in the
function and will be obvious. If the variable is global... Well globals
are quite frowned upon aren't they? Maybe it's the global that needs
some special sort of code. Something to think about.
How about this, quite off the wall but interesting idea. Variables that
have a scope smaller than a function should be 1-2 characters long,
varibles with function scope should be 3-4 characters long, variables
with class scope should be 5-6 characters long, variables with file
scope 7-8 chars and variables with multiple file scope should be greater
than 8 characters. Just an idea...