I may have gotten confused. I'm against prefixes. A name clash can be
okay in certain circumstance to implement a short-hand, but that isn't
most cases and can be eliminated with macros.
Klaim. Using m_ and not using m_, like any convention, is highly
dependent on the rest of your code.
You're saying it's valuable to have the distinction between a member
variable and something else. Intellisense illustrates the value
well. You have a whack of variables and you type m_ to narrow it
down. This might be useful to you. What Twitch is saying is that your
class should be designed in such a way so that you'd never even have
to think about that separation. Do I want an instance variable or not
is a question you don't ever need to ask yourself.
If you have a bob, then all anyone should care about is getting
bob. bob should have a consistent meaning everywhere. The only reason
you'd want to differentiate between a member bob (m_bob) and a regular
bob (bob) is if the name bob doesn't clarify the variables true
meaning to whoever is accessing it.
m_bob = 'member data'
bob = 'local data'
Ok. In this case, you have two bobs. You have m_bob and bob. Foo needs
to tell the difference, for whatever reason. This situation represents
the essential one where prefixes come in. You are trying to
Here you are overriding the meaning of m_bob. m_bob should be the same
everywhere. m_bob should be m_bob in every function in that class. If
it is not, then the meaning of m_bob is different per-function, and
that's bad. A member variable should have consistent meaning for all
functions. That's what makes it a member variable. Classes link
functions to data.
In Foo you are declaring a new bob. So you are saying that 'member
data' is bob, and 'local data' is also bob. There can only be one
bob. bob is the correct name for 'member data' or 'local data'. If bob
is an accurate name for 'member data' then it should be just as
accurate anywhere in the class, anywhere inside Foo. But it isn't.
You are creating this little universe where bob is no longer 'member
data' and is temporarily 'local data.' You are breaking the consistent
meaning of bob. bob is sometimes one thing and sometimes something
else, depending on where you are in the class. You've made a class,
declared it's data then changed that very definition, saying, no
sometimes that's not really what it is. You're saying the meaning of
your data is context-sensitive. The point of an object is to eliminate
context sensitivity, to handle it for you.
If you absolutely have to use bob as the name for 'local data' inside
Foo, then bob is obviously not a good name for 'member data' inside
Foo. If Foo is also inside MyClass, then 'member data' needs a new
name, or it should be taken out of that class.
Am I making sense?
Do you see how two variables are fighting over a definition? They are
both taking precendence. One should win.
Requiring a prefix side-steps the deeper issue of having an unclear
name to begin with. m_bob and bob are actually two entirely different
things. Inside Foo, m_ is a necessary differentiator, why? m_ just
states where something is comming from. It doesn't state what
something is. The naming of something should always declare the "what"
because the "what" is what you need to know to use something properly.
You are using m_ to indicate the "where", then translating the meaning
of a variable inside your head depending on where it is. bob is an
inaccurate name because it doesn't totally describe what something
is. If you find it important enough to differentiate between two
things, then their functions within the program are distinct enough to
give them different names. The functional relevance of a variable to
anyone who uses it should be in its name. A name says, "this is how I
am different from everyone else in my scope in the most important
ways." If you need a bonus identifier, then the functional relevance
of the variable in question is unclear. Critical meaning is
implied. That isn't good.
This idea blends straight into encapsulation. If something needs to
know an implementation detail about something else, then someone is in
the wrong spot or something isn't what it says it is.
In really simple terms, if you ever feel like you need to clash names,
I'll show you that your names are not the best names, or your scope is