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?

+11  A: 

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 mimimalist 'underscore only' keeps it readable.

Matt Howells

Your mul_ example is heading towards Charles Simonyi's Apps Hungarian notation.

I prefer keeping things simple and that's why I like using m_ as the prefix.

Doing this makes it much easier to see where you have to go to see the original declaration.

Rob Wells
+34  A: 

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".

Paul Tomblin
The flaw with not using underscore or m_ is when you have name conflicts between member variable names and member function argument names.
17 of 26
Name conflicts are solved by "this." prefix.
This is not a flaw at all, in my opinion. In c# for example, you can clearly qualify your member variable with this. in case there is a conflict.
petr k.
Solve name conflicts by using better names... ;-)
If you keep your methods short enough to be within a single screen (as I have seen recommended) then a glance to the method declaration is all that's needed to clear up where the variable comes from.
It would be nice if IDE's supported coloring member variables differently from other variables.
Scott Langham
Do you really want to rely on the features of a particular IDE to make your code readable?
@RichQ: I'm not relying on a particular IDE. The IDE syntax highlighting is an aid for people with weak memories who can't remember what's a local variable in a one page method - thats why I said "or a decent memory".
Paul Tomblin
Paul, I was responding to Scott who said "It would be nice if IDE's supported coloring member variables differently from other variables". I'm a staunch m_-er, but I am now doubting having read some comments here..
Eclipse does colour member variables differently and I'm sure you could coerce Vim/Emacs/other non-sucky editors to do the same.
Aaron Maenpaa

None if it's not necessary, single underscore otherwise. Applies for python.

Florian Bösch
+19  A: 

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.

petr k.
Can those giving me down votes please clarify? The question is "what do you use", not "what is the best and only way". Even if it was "what is the best and only way", certainly everyone can have very different point of view as to what works best for him as an individual, isn't that right?
petr k.
I'm with you on this one. If you can't tell your locals from your members, you're putting too much stuff into one place. Better keep one's functions simple.
Religion knows no sense. In any event, your rep is intact using the 5-1 ratio of upvote points to downvote points.
I'm with you on this one. I must admit that I sometimes write long methods as well, but I do know full well that I SHOULD refactor them to something more sane. (using C#) if there's ever an ambiguity, you can always use the 'this' keyword.
Erik van Brakel
It's useful when you are passing a variable into a functionFunction(int value) { m_value = value; }Otherwise you have to think of two different names for 'value'
Martin Beckett
@mgb - you could also do: Function(int value) { this.value = value; }
+17  A: 

No doubt, it's essential for understanding code to give member variables a prefix so that they can easily be distinguished from "normal" variables.

I dispute this claim. It's not the least bit necessary if you have half-decent syntax highlighting. A good IDE can let you write your code in readable English, and can show you the type and scope of a symbol other ways. Eclipse does a good job by highlighting declarations and uses of a symbol when the insertion point is on one of them.

Edit, thanks slim: A good syntax highlighter like Eclipse will also let you use bold or italic text, or change fonts altogether. For instance, I like italics for static things.

Another edit: Think of it this way; the type and scope of a variable are secondary information. It should be available and easy to find out, but not shouted at you. If you use prefixes like m_ or types like LPCSTR, that becomes noise, when you just want to read the primary information – the intent of the code.

Third edit: This applies regardless of language.

Kevin Conner
That's right, but we sometimes use printouts for code reviews. Without a color printer, you will have no highlighting ...
So without a color printer for the 1% of your time you spend on code reviews, you have to spend the other 99% with hard-to-read code? Talk to your boss about a printer.
Kevin Conner
Or a projector, for that matter.
Kevin Conner
Maybe I should regonfigure my syntax highlighting ... One up for your statement, Kevin.
Thanks :) Another alternative: Kinko's.
Kevin Conner
There are other ways to highlight syntax than colour. See the various pretty printers that italicise, embolden, or switch fonts.
Excellent point. Editing the post to include that..
Kevin Conner
I comletely agree with Kevin disputing this claim, and if he did not write this answer I would have done. It really is not essential for understanding code. I can, and have, understood vast amounts of code that did not have prefixed member variables.
Greg Whitfield
While this holds for languages designed to be parsed in an IDE, such as Java or C#, it does not for C++ nor C (where some struct members each have a prefix *unique to that specific struct*). This is, IMNSHO, very language-specific, just like most syntax.
Roger Pate
+2  A: 

It kinda depends what language you're working in.

In C# you can reference any member using the 'this' prefix, e.g. 'this.val', which means no prefixes are needed. VB has a similar capability with 'Me'.

In languages where there is a built-in notation for indicating member access I don't see the point in using a prefix. In other languages, I guess it makes sense to use whatever the commonly accepted convention is for that language.

Note that one of the benefits of using a built-in notation is that you can also use it when accessing properties and methods on the class without compromising your naming conventions for those (which is particularly important when accessing non-private members). The main reason for using any kind of indicator is as a flag that you are causing possible side effects in the class, so it's a good idea to have it when using other members, irrespective of whether they are a field/property/method/etc.

Greg Beech
+3  A: 

It really depends on the language. I'm a C++ guy, and prefixing everything with underscore is a bit tricky. The language reserves stuff that begins with underscore for the implementation in some instances (depending on scope). There's also special treatment for double underscore, or underscore following by a capital letter. So I say just avoid that mess and simply choose some other prefix. 'm' is ok IMO. 'm_' is a bit much, but not terrible either. A matter of taste really.

But watch out for those _leadingUnderscores. You'll be surprised how many compiler and library internals are so named, and there's definitely room for accidents and mixup if you're not extremely careful. Just say no.

Assaf Lavie
If you want to use underscores, trailing underscores are the way to go in c++.
Greg D
+5  A: 

I prefer using this keyword. That means or this->data instead of some community dependant naming.


  • with nowadays IDEs typing this. popups intellinsense
  • its obvious to everyone without knowing defined naming

BTW prefixing variables with letters to denote their type is outdated with good IDEs. And remembers me of this Joel's article

Jakub Kotrla
This is not a good practice, because it's easy to forget this ;)
+4  A: 

It depends on which framework I'm using! If I'm writing MFC code then I use m_ and Hungarian notation. For other stuff (which tends to be STL/Boost) then I add an underscore suffix to all member variables and I don't bother with Hungarian notation.

MFC Class

class CFoo  
    int m_nAge;  
    CString m_strAddress;  
    int GetAge() const { return m_nAge; }  
    void SetAge(int n) { m_nAge = n; }  
    CString GetAddress() const { return m_strAddress;  
    void SetAddress(LPCTSTR lpsz) { m_strAddress = lpsz; }  

STL Class

class foo  
    int age_;  
    std::string address_;  
    int age() const { return age_; }  
    void age(int a) { age_ = a; }  
    std::string address() const { return address_; }  
    void address(const std::string& str) { address_ = str; }  

Now this may seem a bit odd - two different styles - but it works for me, and writing a lot of MFC code that doesn't use the same style as MFC itself just looks ugly.

In MFC it's useful to have m_ for a variable associated with the contents of a control and c_ for the control itself. Otherwise you have to think up two different names for the same item.
Martin Beckett

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)

+5  A: 

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".

Seb Nilsson
Agree, however FYI:MS Framework Design Guidelines 3.6.4 Naming Fields "The field naming guidelines only apply to static public and protected fields. Internal and private fields are not covered by the guidelines and public or protected fields are not allowed according to ..."
Robert Paulson
I'm using the Framework Guidelines-book as reference, so it may be a bit behind. Or I remember wrong. Can you link to your statement? From what I remember it says "private fields are not covered... but it is recommended that..." or something like that.
Seb Nilsson
How do these two statements collide? the private members are not accessible nor used by other classes in other languages.

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.


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.

+2  A: 

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.


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
+1  A: 

I use camel case and underscore like many here. I use the underscore because I work with C# and I've gotten used to avoiding the 'this' keyword in my constructors. I camel case method-scoped variants so the underscore reminds me what scope I'm working with at the time. Otherwise I don't think it matters as long as you're not trying to add unnecessary information that is already evident in code.

Daniel Crenna
+2  A: 

Most of the time, I use python. Python requires you to use in order to access the attribute foo of the instance of the current class. That way, the problem of confusing local variables, parameters and attributes of the instance you work on is solved.
Generally, I like this approach, even though I dislike being forced to do it. Thus, my ideal way to do thos is to not do it and use some form of attribute access on this or self in order to fetch the member variables. That way, I don't have to clutter the names with meta-data.

+7  A: 

It's more important to be consistent than anything, so pick something you and your teammates can agree upon and stick with it. And if the language you're coding in has a convention, you should try to stick to it. Nothing's more confusing than a code base that follows a prefixing rule inconsistently.

For c++, there's another reason to prefer m_ over _ besides the fact that _ sometimes prefixes compiler keywords. The m stands for member variable. This also gives you the ability disambiguate between locals and the other classes of variables, s_ for static and g_ for global (but of course don't use globals).

As for the comments that the IDE will always take care of you, is the IDE really the only way that you're looking at your code? Does your diff tool have the same level of quality for syntax hilighting as your IDE? What about your source control revision history tool? Do you never even cat a source file to the command line? Modern IDE's are fantastic efficiency tools, but code should be easy to read regardless of the context you're reading it in.


For my own projects I use _ as a postfix (as Martin York noted above, _ as a prefix is reserver by the C/C++ standard for compiler implementations) and i when working on Symbian projects.

+3  A: 

I prefix member variables with 'm' and parameters (in the function) with 'p'. So code will look like:

class SomeClass
    private int mCount;
    private void SomeFunction(string pVarName){...}

I find that this quickly tells you the basic scope of any variable - if no prefix, then it's a local. Also, when reading a function you don't need to think about what's being passed in and what's just a local variable.

+4  A: 

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:

  1. Increases the human comprehension of code without using the IDE. As in code review -- which I still find easiest to do on paper initially.
  2. Ever write T-SQL or other RDBMS stored procs? Using prefix notation on database column names is REALLY helpful, especially for those of us who like using text editors for this sort of stuff.

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.


In Java, one common convention is to preface member variables with "my" andUseCamelCaseForTheRestOfTheVariableName.

Matt J
+1  A: 

I've used to use m_ perfix in C++ but in C# I prefer just using camel case for the field and pascal case for its property.

private int fooBar;
public int FooBar
  get { return fooBar; }
  set { fooBar = value; }
+1  A: 

I'm with the people that don't use prefixes.

IDEs are so good nowadays, it's easy to find the information about a variable at a glance from syntax colouring, mouse-over tooltips and easy navigation to its definition.

This is on top of what you can get from the context of the variable and naming conventions (such as lowerCamelCase for local variables and private fields, UpperCamelCase for properties and methods etc) and things like "hasXXXX" and "isXX" for booleans.

I haven't used prefixes for years, but I did used to be a "this." prefix monster but I've gone off that unless absolutely necessary (thanks, Resharper).

David Moore

I'm weirdo and I prefix member variables with initials from the class name (which is camel-cased).

TGpHttpRequest = class(TOmniWorker)
strict private
  hrHttpClient  : THttpCli;
  hrPageContents: string;
  hrPassword    : string;
  hrPostData    : string;

Most of the Delphi people just use F.

TGpHttpRequest = class(TOmniWorker)
strict private
  FHttpClient  : THttpCli;
  FPageContents: string;
  FPassword    : string;
  FPostData    : string;

No prefix. And, for purely functional / stack based no variable name. But if I really have to use side effects which I may if I want to output anything then I use p-> where p is an external Pointer to Parameters Passed to my function.

I think using a prefix / prefixes gets silly.


Mulling over the mul example, my member variable which is an unsigned long representing the opcode for a multiply instruction might be mulmul.

Mark Stock
+2  A: 

A single _ used only as a visual indicator. (C#)

  • helps to group members with intellisense.
  • easier to spot the member variables when reading the code.
  • harder to hide a member variable with a local definition.
Robert Paulson

Symbian uses 'i' as a prefix for members and 'a' for parameters.


I only use a _ suffix (the prefix _ is reserved in c/c++ as many have noted above). I like it mainly because I hate parameter names like 'aCircle', and I don't like writing out either unless absolutely necessary. (I only do that for public access member variables, 'cos for these I don't use the underscore suffix).

+2  A: 

If the language supports the this or Me keyword, then use no prefix and instead use said keyword.


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