What kind of prefix do you use for member variable

Question

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?

Answer 1

I do not use any prefix at all. If I run into danger of mixing up local variables or method parameters with class members, then either the method or the class is too long and benefits from splitting up.

This (arguably) not only makes the code more readable and somewhat "fluent", but most importantly encourages well structured classes and methods. In the end, it thus boils down to a completely different issue than the prefix or no-prefix dillema.

UPDATE: well, taste and preferences change, don't they.. I now use underscore as the prefix for member variables as it has proven to be beneficial in recognizing local and member variables in the long run. Especially new team members sometimes have hard time when the two are not easily recognizable.

Answer 2

Using C#, I've moved from the 'm_'-prefix to just an underscore, since 'm_' is an heritage from C++.

The official Microsoft Guidelines tells you not to use any prefixes, and to use camel-case on private members and pascal-case on public members. The problem is that this collides with another guideline from the same source, which states that you should make all code compatible with all languages used in .NET. For instance, VB.NET doesn't make a difference between casings.

So just an underscore for me. This also makes it easy to access through IntelliSense, and external code only calling public members don't have to see the visually messy underscores.

Update: I don't think the C# "this."-prefix helps out the "Me." in VB, which will still see "Me.age" the same as "Me.Age".

Answer 3

Since VB.NET is not case-sensitive, I prefix my member variables with an underscore and camel case the rest of the name. I capitalize property names.

Dim _valueName As Integer

Public Property ValueName() As Integer

Answer 4

I like m_ but as long as convention is used in the code base is used I'm cool with it.

Answer 5

None. I used to use underscore, but was talked out of it on a project where the others didn't like it, and haven't missed it. A decent IDE or a decent memory will tell you what's a member variable and what isn't. One of the developers on our project insists on putting "this." in front of every member variable, and we humour him when we're working on areas of code that are nominally "his".

Answer 6

another trick is naming convention:

All member variables are named as usual, without any prefix (or 'this.' is it is usual to do so in the project)

But they will be easily differentiated from local variable because in my project, those local variables are always named:

• aSomething: represents one object.
• someManyThings: list of objects.
• isAState or hasSomeThing: for boolean state.

Any variable which does not begin by 'a', 'some' or 'is/has' is a member variable.