No doubt, it's essential for understanding code to give member variables a prefix so that they can easily be distinguished from "normal" variables.
But what kind of prefix do you use?
I have been working on projects where we used m_ as prefix, on other projects we used an underscore only (which I personally don't like, because an underscore only is not demonstrative enough).
On another project we used a long prefix form, that also included the variable type. mul_ for example is the prefix of a member variable of type unsigned long.
Now let me know what kind of prefix you use (and please give a reason for it).
EDIT: Most of you seem to code without special prefixes for member variables! Does this depend on the language? From my experience, C++ code tends to use an underscore or m_ as a prefix for member variables. What about other languages?
I tend to use m_ in C++, but wouldn't mind to leave it away in Java or C#. And it depends on the coding standard. For legacy code that has a mixture of underscore and m_ I would refactor the code to one standard (given a reasonable code size)
If it is really necessary to prefix member variables, I would definitely prefer
m_
to just an underscore. I find an underscore on its own reduces readability, and can be confused with C++ reserved words.However, I do doubt that member variables need any special notation. Even ignoring IDE help, it isn't obvious why there would be confusion between what is a local and what is a member variable.
We use m_ and then a slightly modified Simonyi notation, just like Rob says in a previous response. So, prefixing seems useful and m_ is not too intrusive and easily searched upon.
Why notation at all? And why not just follow (for .NET) the Microsoft notation recommendations which rely upon casing of names?
Latter question first: as pointed out, VB.NET is indifferent to casing. So are databases and (especially) DBAs. When I have to keep straight customerID and CustomerID (in, say, C#), it makes my brain hurt. So casing is a form of notation, but not a very effective one.
Prefix notation has value in several ways:
Maybe in short, prefixing as a form of notation is useful because there are still development environments where smart IDEs are not available. Think about the IDE (a software tool) as allowing us some shortcuts (like intellisense typing), but not comprising the whole development environment.
An IDE is an Integrated Development Environment in the same way that a car is a Transportation Network: just one part of a larger system. I don't want to follow a "car" convention like staying on marked roads, when sometimes, its faster just to walk through a vacant lot. Relying on the IDE to track variable typing would be like needing the car's GPS to walk through the vacant lot. Better to have the knowledge (awkward though it may be to have "m_intCustomerID") in a portable form than to run back to the car for every small change of course.
That said, the m_ convention or the "this" convention are both readable. We like m_ because it is easily searched and still allows the variable typing to follow it. Agreed that a plain underscore is used by too many other framework code activities.
Underscore only.
In my case, I use it because that's what the coding standards document says at my workplace. However, I cannot see the point of adding m_ or some horrible Hungarian thing at the beginning of the variable. The minimalist 'underscore only' keeps it readable.
I use @.
:D j/k -- but if does kind of depend on the language. If it has getters/setters, I'll usually put a _ in front of the private member variable and the getter/setter will have the same name without the _. Otherwise, I usually don't use any.
In Java, one common convention is to preface member variables with "my" andUseCamelCaseForTheRestOfTheVariableName.