In some programming languages, the scope of an object is encoded into its name somehow. This is often enforced by various coding standards (myVariableName, theVariableName, aVariableName, _variableName, m_variableName). The following languages enforce a naming convention in the language definition.

	* RubyLanguage requires that you prefix instance variables with @, class (static) variables with @@ and global variables with $. Variables without a prefix are local.

----

This originally struck me as a good idea, but I'm less certain now. It does give you a standard way of differentiate between object the parameter and @object the instance variable, but it can be such a pain to type. I've lost count of the times I've had my tests fail because I've left out my @'s. The global prefix also causes me occasional confusion, having started programming in BasicLanguage and seeing the $ sign makes my think "it's a string, a string I say!", but I'm slowly getting over it. -- DanielSheppard

This idiom strikes me as a room freshener deployed agaisnt the stench of a dead rat under the floor. When looking at the text of a method 1) why should I care, in general, if an identifier is method, object class or globally scoped? If I do care, I can go and look. Which brings me to 2) if the method body is so long that when looking at any part of it I can't see the whole thing (including argument list and declaration (if any) of locals) then isn't that a severe smell? and 3) if the method argument list and/or class definition are so long that I can't tell at a glance where my identifier was declared, then isn't that a strong smell? Wouldn't it be better to fix all these things, rather than stick some HungarianNotation style warts on the identifier to patch thing up?

In C/C++ maybe, just maybe, this is worth doing, since you're almost certainly doing at least some manual memory management. At which point maybe it's worth flagging which identifiers denote values on the heap and which on the stack, but you probably can't do that consistantly and universally.

----
A common C++ convention is to declare member variables with an m_ prefix. Global variables get a g_ prefix, and method arguments have no prefix. Dereferenced variables do not usually have a naming convention(beyond using an asterik)

I can think of two good arguments for prefixing the name with the scope(not heap vs. stack, but members vars vs. method vars):
* Method code is more readable when you can easily discern member variables from method argument variables.
* With legacy code, there is usually a bunch of global variables sitting around. They should be refactored, but prepending g_ beforehand makes it go more cleanly. . . and is a big help if you never get the resources to refactor.

----

See NameImpliesType