Field names…

There are three common choices for field name conventions in C# code:

  1. No prefix ("string name;")
  2. Underscore ("string _name;")
  3. MFC-style ("string m_name;")

I label the third MFC-style because that's where I first encountered it.

In the past, I haven't expressed a strong opinion for any of these, and I've written some C# code that used style #1 and some that used style #3. I recent experience, however, has pushed me in one direction.

On Monday, I did two separate code reviews. One was for a C++ class that one of my teammates has written (we do code reviews on all of our code), and the second was on a C# sample written by a C# PM.

When I was reading the C# code, it was hard to follow in places, and it took me a while to realize that what I was missing being able to know instantly whether an identifier was a field, or whether it was a parameter or local.

So put me firmly in the MFC-style camp for naming. #2 is also a reasonable choice, but I think it feels to much like a compiler-defined construct for my taste. Thankfully, I'll have refactoring when I need to revisit my old C# code...


Comments (41)

  1. Luciano Passuello says:

    My choice is #1, but I always reference the variable as "this.variable" in the code. Keeps the variable name "clean" and shows explicitly (via a language construct) the intention.

  2. Code Monkey says:

    Agreed — it’s all too easy to leave off the "this." notation to indicate a field (assuming that the reference is unambiguous), and it just feels too wordy. Besides, everybody knows what "m_" means and I find it a very useful visual cue.

    You could also argue that the compiler could offer some color-coding support here: local in fuscia, parameters in mauve, fields in hot pink. The counter-argument is that there’s a learning curve associated with it, and having so many color codings might decrease the utility of color highlighting in general. Still, I wouldn’t mind seeing it as an option. Have you guys played around with this at all?

    BTW, do you like to distinguish member vars apart from parameters using prefixes?

  3. Dmitry Shaporenkov says:

    We use prefix ‘my’ for instance fields and ‘our’ for static ones. This usually looks find though sometimes resutls in werdly-looking phrases (like ‘bool myIsInitialized’)

  4. Dmitry Shaporenkov says:

    We use prefix ‘my’ for instance fields and ‘our’ for static ones. This usually looks fine though sometimes results in weirdly-looking phrases (like ‘bool myIsInitialized’)

  5. Adam Young says:

    Ditto for me. What you call MFC style is Hungarian notation, which is deprecated these days in favour of the .net framework design guidelines (

  6. I tend to use method one.

    Except when dealing with underlying property fields, then I use method 2.

    As far as I know that is how it should be done according to the microsoft msdn naming convention.

  7. I personally use a convention I started to use with C++, many years ago, after reading Marshall Cine’s C++ FAQ:

    i.e: I write string name_;

  8. Wedgebert says:

    Well, I know I’m a *lowly* programmer :), so that rules out #1 for me, so I tend to stick to #3. However I also try to use the property for get/set whenever possible on the rationale that I might have validation logic in there and it makes sense to validate inside the class as well as with external data.

  9. Krishna says:

    I use one, VS does a nice job of giving the definition hints through tooltips to identify if its local variable, field or a parameter and its cleaner to read this notation in calculation intensive code

  10. Scott says:

    Using tooltips to identity variable types sucks. You can’t determine scope using the tooltips and you have to wait for the tooltip to show up. If it shows up at all, if it doesn’t you have to move the mouse cursor around and wait again. Programming isn’t about clicking a mouse button or moving a pointer around, it’s about creating code.

    We recently hired a guy who was on the Visual Studio team at MS. He uses what you call the MFC naming convetions. We recently did a code review of some C# code he wrote and it’s much easier to read than my code written to the CLR guidelines.

    I’m more into "smart prefixing". If the var crosses physical files, e.g. the id of a control in an ASP.NET page and the reference to it in the code behind class, I’ll prefix it with something idetifying the type of the control. Like the old VB notation. txtUserName, cboState (or ddlState).

  11. David Hayden says:

    I just can’t get into putting "this." in front of member variables in C#. I am not sure when or why I started it, but I always prefix member variables with "_" as in #2. It makes it really easy to do code reviews.

    "m_" would probably be my second choice, but that requires one more unnecessary keystroke in my opinion to add the "m".

    Anything like "mstr" or "mstr_" in front of string member variables, for example, gives me a headache. I actually have to process that prefix, which often distracts me from my goal of reviewing the code. It is a few more keystrokes as well. A lot of people like it and are more comfortable with it, however, so to each his/her own.

    As long as the developer is consistent throughout the code and has some differentiation between member variables and local variables/parameter, I can deal with it. As for myself, I want to keep it very simple and type the least amount as possible.

  12. I find the convention of declaring variables just before you first use them (in a function) to be helpful in determining scope. In combination with keeping functions as short as possible, naming conventions become much less important.

    In VB.NET I will prefix private variables with _, just to distinguish them from public properties. This is not necessary in C#, because of case sensitivity (name != Name).

    So, for C# (1) is best for me, and in VB.NET I use (2). I agree with Code Monkey that the IDE could make this more obvious through color coding.

  13. Jim Holmes says:

    I’m in Steve McConnell’s camp: use *some* sort of method to distinguish class members from global and local. It’s taken me awhile to get used to it, but m_variable (option #3) has grown on me. I agree about option #2 being confusing with compiler directives.

    I also think one shouldn’t rely on IDE functionality to make code readble. IDEs change and not everyone uses the same IDE. Some folks even do code reviews via hardcopy. <gasp!>

    Make the code read clearly in all environments, not just one.

  14. Curt says:

    "…IDE could make this more obvious through color coding"

    I use Eclipse when I’m doing Java work, which formats the various instance members, class members, etc. differently. To my chagrin I find it difficult to remember what the various formatting means…

  15. Srdjan says:

    we use:

    – no prefix for class fields,

    – (2) for method fields and

    – prefix ‘p’ for parameters.

    Also, all private class members, including methods, start with lower case.

    Simple and works great during development and for code reviews.

  16. James Curran says:

    As a side note, style (2) would actually be "illegal" in C++, where identifiers starting with an underscore are reserved (for either the compiler or library)

  17. Thomas Eyde says:

    If you are confused about the scope of a variable, you can take it as a sign that your method is too big, or perhaps the class is.

    If you have to use a local variable with the same name of a class variable, then you may have duplicated code or a class which do too much or do unrelated things.

    The following code:

    Action action = new Action();

    action.Do("one", a, b);

    action.Do("two", a, b);

    action.Do("three", a, b);

    Can be refactored to:

    Action action = new Action(a, b);




    In this case a and b are available to the whole class. The Do-method should not need to declare variables named a or b.

  18. I thought #2 was the recommended MS coding guideline. At least, it’s the one we standardized on in ASP.NET.

  19. David says:

    1. Agree with Thomas–if you can’t figure out easily whether a variable is local or a member, it’s time to refactor (I should know, I have plenty of places where this is true…).

    2. You should be using Source Insight, which has gojillions of features to help with this, including color-coding based on type of variable (member vs. local vs. global vs. …), a context window that displays the declaration of whatever you have your cursor on, et al. It’s all that and a bag of chips! (No affiliation, other than hoping they continue to do enough business to release new versions :).)

  20. Sean Malloy says:

    ReSharper already allows you to change the syntax for fields, locals, parameters, events etc. Simple, $99 and you can have it too.

  21. Although C# inherited the C++ syntax, it has some roots in Delphi, too (go Anders!). While the C++ convention is "m_" (as in m_MyField), the Delphi convention is "f" (as in fMyField). I have tried the MS guidelines, but prefer to use "f" (don’t knock it till you’ve tried it! :-). Read about why I like "f" (other than not forgetting those roots) at

  22. I have to agree with Thomas Eyde. While I used to be a user of the MFC-style (when I was progamming MFC code) and then leading underscore style, I have since learned that when my methods and classes are properly factored, I don’t have any ambiguity.

    When you can see then entire method on the screen without paging, then either it is defined in this scope, or it is a field. Simple.

    In fact, I don’t use the "this.myField" notation either, except in constructors. I often end up with constructors like this:

    public class Foo


    public Foo( string name )

    { = name;



  23. Jason Mackay says:

    c# style use camel casing for all variables, and if you keep your methods short you should be able to easily identify parameters from members by quickly looking at the function signature. I use the rule of thumb that if a function is bigger then one page in your editor it is time to look at making a new class or function. I have no problems having dropped all hungarian notation from good oop code.

  24. Chris Nahr says:

    I use #2 and a this. prefix to boot. This combo saves a lot of time in Visual Studio because I can type "this._" and get a list of all my class variables.

    As for the possible confusion with compiler directives — while the C# standard does reserve two initial underscores for use by the compiler, there are currently no such things either present or planned AFAIK. And a single underscore is not reserved anyway.

  25. I prefer using "m_" (instead of #1 or #2) because it gives me the option to use "s_" for private static members and "c_" for controls/components. This notation works very well with intellisense, and even better when combined with VB-style Hungarian (see

  26. Thomas Eyde says:

    I support prefixing with "this." in constructors. This practice removes silly mistakes like assigning something to itself.

    I find it easier to refactor when I use the same naming conventions all over the place: camelCase for all locals, PascalCase for all publics.

  27. Stu Smith says:

    I like to use #2, however, the existence of System._AppDomain really screws up the lovely Intellisense in Whidbey. If I press ‘_’ I want my member variables, not some random badly-named interfaces.

  28. Luc Cluitmans says:

    I myself use a style that I did not see listed before. I have been using it for years already, so I lost where I picked it up, but my best guess is that it was inspired by Borland’s Delphi library code. So feel free to call it ‘Delphi style’.

    The style is this: I use a capital ‘F’, followed by the field’s name written with an initial capital, so Eric’s original example would be:

    private string FName;

    Note how this style is similar to the more common convention of prefixing interface names with a capital ‘I’.

    I have found this style very useful, because it means that any identifier that does not start with a capital is a local variable (or argument), and I know that using or modifying it will have only local effects within the method.

    As a variation on this, I use the prefix ‘G’ (for ‘Global’) on any static fields. Once again, this makes it easy to see what the scope of a write to a field is; If I am writing to a field prefixed with a ‘G’ in code that I wrote some time ago, I know I should be extra careful not to cause undesirable side-effects.

  29. Eric Gunnerson discusses field names in C# code. As mentioned before my preference is his option #2, underscore ("string _name"). One reason is that you don’t have to think so much when naming constructor parameters used to initialize member variables:…

  30. Ryan Heath says:

    I am in camp III, but slowly moving towards camp I with a this. prefix. but lately I came across a case in which I wished I had used m_.

    I made a spelling error, but no compiler and no intellisense complaint, and I just kept wondering why that member variable was not initialing… As a matter of fact, it was with the help of intellisense that I made that error.

    Can you spot it? 😉

    class SomeClass


    public string subscriptionMessage;

    public string unsubscriptionMessage;

    public string errorMessage;

    public SomeClass( string subscriptionMessage, string unsubscriptoinMessage, string errorMessage)


    this.subscriptionMessage = subscriptionMessage;

    this.unsubscriptionMessage = unsubscriptionMessage;

    this.errorMessage = errorMessage;



  31. it's all in the mix says:

    It’s not about using simplistic rules it’s about the key goal:

    Can someone else* understand this quickly with little or no chance of errors.

    If you always try to keep variable scope extremly short then a lot of the prefixing usage becomes redundant (so it begins to hinder not help as you duplicate the information).

    Using this. in front of instance variables is also far more preferable since it make auto completion kick in. Unfortunately current visual studio behaviour is annoying when you have variable/property with identical names bar case – if I type in a lower case letter give me the lowercase one first dammit!!!**.

    One area lack of prefixes can cause confusion with is in constructors this prefixes should be mandatory (not at the compiler level I mean as a coding guideline)(I really should make that an FxCop rule at some point)

    I admit that static variables are an area that might benefit from an our. or class. (maybe static. would be non breaking).

    * you in 6 months time counts as someone else ;¬)

    ** Sorry but if you could feed that back to the VS developers that would be good

  32. Personally, I like the naming convention advocated by Scott Meyers, and Andrei Alexandrescu:

    string name_;

    It doesn’t feel like a compiler generated construct, the naming doesn’t interfear with readability or asthetics, and its meaning is pretty clear.

  33. Thomas Eyde says:


    string name_;

    even works in VB6:

    Dim name_ As String

    But that’s a pure coinsidence, I guess?

  34. Daniel Moth says:

    ‘m’ for fields

    ‘a’ for in parameters

    ‘the’ for out paramters

    ‘aThe’ for inout params

    ” for local vars (i.e. no prefix)

  35. Jason Cone says:

    I seem to be in the minority, but I can’t stand prefixes on variable names. Spare me from ever working with Hungarian-notated code! Put me in camp #1.

    If approach #1 was not an option for some reason, then appending an underscore seems like a reasonable (and less obtrusive) compromise.

  36. duncan says:

    Since I hate trying to type lots of _’s (shifted characters are bad m’kay) I prefix member variables with just the ‘m’:


    otherwise no prefixes allowed.

  37. Michael Cook says:

    #3 is too much, #1 is too little, #2 is just right 🙂

Skip to main content