A week or two ago, I read an interesting article in Coding Horror called The Problem With Code Folding. Let me quote the beginning of this post:

When you join a team, it’s important to bend your preferences a little to accommodate the generally accepted coding practices of that team. Not everyone has to agree on every miniscule detail of the code, of course, but it’s a good idea to discuss it with your team and decide on overall approaches and philosophy beforehand. It promotes team harmony, and more than that, it’s just common courtesy. As they say, when in Rome, do as the Romans do. 

Jeff Atwood is talking about the fact that it is important to obey the coding conventions and practices of your team. Every one of us as its own preferences but as a team we need to have some rules, we all should work with the team, not against it. I must admit that I totally agree with Jeff’s attitude, no questions about it.

But, in addition to what was said before, Jeff continues:

Still, there are some coding preferences people may feel.. strongly.. about. If that’s the case, try to clear the air and address those strong preferences up front, as early as possible. Don’t let them simmer. For me, the use of #region is one of those things. I tried to make myself clear in this twitter message: No, I will not use #regions. And no, I DO NOT NEGOTIATE WITH TERRORISTS. Shut up.

I am not going to talk about the #regions issue, but to have my own say about another coding preference:

Yes, I will use m_ prefix for class members. I DO NOT NEGOTIATE WITH TERRORISTS. Shut up. 

Actually, I don’t mind which prefix shall be used but in order to make member variables distinct from local variables, we have to give it some prefix. This is a part of a coding convention for C++ adopted by Microsoft called Hungarian notation. Some of you may say that it may be a bit disturbing using C++ naming conventions in C# code, but I don’t see the big difference. The rational in C++ for a prefix like m_ is that in the initializer list, some compilers, won’t let you use “this” for scope resolution.  So, to avoid having parameter name collisions with fields, “m_” is used to delineate fields. If that is the only reason why C# doesn’t need the prefix, I have to state that this is not enough.

Not having a prefix for class members is horrible for readability, when I see a method implementation without m_ being used, I have to scroll around to find out where each variable came from, it is very annoying. Some people are refusing to use prefix’s because the variable name becomes a little bit longer (2 characters longer, to be precise), but those people are just fine with writing “this.” (a five-character prefix). funny, isn’t it?

Another reason to use m_ is the IntelliSense. If you start typing m_, you get all of the class members and only them, not having to find your variable in a long scrollable window. It is very convenient and it provides a sense of some logical order. But, the most important part is that most developers are not using “this.” when they use class members and it may produce an error prone code. Take a look at the following code:

private int variable = 0;
void DoSomething()
{
    int variable = 0;
    variable = 9;
}

Which variable is set to 9? The local variable or the class member? The answer is: the local one. This is a little example, so you may say that when coding right, this situation shall never happen… I say that in big projects, it may happen and I am almost sure it happened to you at least once as well!

What do you think? Do you use m_? Do you have good thing to tell about not using prefixes? Because I can’t see any…

Tags :

30 Responses to “Coding Conventions – Prefix For Class Members”


  1. Michael Campbell

    Said on July 16, 2008 :

    I use an unadorned leading “_” (but this is in Java), and have for years, and will probably continue, even though my team hates it. I’m older than all of them anyway, so have grown used to being the crusty curmudgeon.

    That said, some IDEs (eclipse for Java for example) can color member variables differently than parameters to the current method and differently yet from local variables, which does eliminate *SOME* need for the visual cues.

    But I don’t negotiate either.

  2. Greg Beech

    Said on July 16, 2008 :

    The “this” prefix is better because you’re using a compiler-enforced assertion that this is a member of the class, rather than the metasyntactic convention “m_” or “_” which has no meaning to the compiler.

    Our coding standards mandate the use of the “this” prefix for accessing any member (including methods, properties etc.) which means you also have a consistent compiler-enforced convention for indicating access to a member. You’re not going to start beginning all your properties and methods with “m_” are you?

    So in the interests of both compile-time correctness and consistency across accessing any instance member, you should use “this” not “m_”.

  3. Shahar Y

    Said on July 16, 2008 :

    @Greg
    “You’re not going to start beginning all your properties and methods with “m_” are you?
    ” – of course not, but I don’t understand why is it related? The problem with class members is that there are local variables and input variables to some methods. We need to distinguish them one from each other, you don’t have this problem with properties and methods…

  4. Greg Beech

    Said on July 16, 2008 :

    Well for a start it’s related because methods can be variables. If it’s important to distinguish between class-level and method-level variables, then presumably you’d want to also distinguish between class-level and method-level methods?

    In addition, properties are accessed in a syntactically similar manner to fields (and if you have a local const field then it will also start with a capital letter if you follow Microsoft’s naming conventions). So once again there is a case where you want some way to clearly see whether you are using a class-level property (which may be a simple wrapper around a field) or a method-level variable.

    By using the “this” prefix across all class-level instance members, you can always see when you are accessing resources that are non-local to the method, without requiring any particular naming or metasyntactic conventions. Surely that’s a win?

  5. David Seiler

    Said on July 16, 2008 :

    void f() {}

    void DoSomething(Callback f)
    {
    f()
    }

    Which f is called? The local one, duh. It’s easy to see this because there aren’t all that many callback parameters to begin with, and if you have lots of them with overlapping names you can rename them or refactor the problematic method into several.

    If you find yourself needing to use m_ to distinguish variables belonging to the scope from variables belonging to the object, consider splitting your long methods into several short ones. This aids readability and testability, and makes it easier to distinguish among object variables at a glance.

  6. Ian Suttle

    Said on July 16, 2008 :

    My preference is to use the “_” prefix on all private member fields. I definitely think some sort of identifier to provide clear understanding of field scope is important for ease of reading although “m_”, “_”, “this.”, all serve this role. At the end of the day it’s whatever the team feels is most proper.

  7. Niki

    Said on July 16, 2008 :

    Do you also prefix your classes with a C, to distinguish them from methods? Do you put a p_ in front of every property? N in from of namespaces? Why not?

    Personally, I think if you have to search where a variable comes from, your method is too long and should be refactored.

  8. Schneider

    Said on July 16, 2008 :

    My preference is to use the m_ the main reason is the “_” looks too much like a line continuation in VB.NET; I use both languages a lot so it tends to be confusing.

    Also obfuscators seem to like it…

    Not doing it at all is not an option!

  9. Shahar Y

    Said on July 16, 2008 :

    @Niki
    “Personally, I think if you have to search where a variable comes from, your method is too long and should be refactored.” – My methods are ever longer than a “screen” and still it may be confusing! And, by the way, when you are working in a team, not everybody obeys that rule (short methods) – it is not a perfect world and you may want to create rules which will help readability.

  10. Greg Beech

    Said on July 16, 2008 :

    @David, @Niki

    The purpose of using an instance qualifier is to make it more obvious where and when you’re accessing something that is non-local to the method; that you’re accessing something that may have side effects.

    It’s not necessary, but it’s a useful trigger that you need to think just a little bit more about what you’re doing with them. And anything that helps you to write more correct code is useful, right?

  11. Dmitry

    Said on July 16, 2008 :

    What about static variables?

  12. Dave Bauman

    Said on July 17, 2008 :

    I always use an access keyword–this, base, or StaticClassName–to reference variables, methods, properties, etc. It’s not about typing less code; it’s about being as clear and accurate as possible.

    Microsoft gave C# a this keyword for a reason. Two characters is hardly justification to ignore it and continue using an outdated convention born decades ago out of necessity. A prefix also won’t solve the ambiguity of base vs. this.

    I also use explicit access modifiers. If you leave it off a class, it defaults to internal. When I look at that class, how *I* know you actually meant internal, and didn’t just forget?

    I hate looking at code that doesn’t follow this standard. It’s almost as bad as code using the new var keyword. Both look just plain sloppy to me. My time is expensive, and if I have to spend it trying to figure out what a line is doing in the middle of a function, it’s time wasted.

  13. David Kemp

    Said on July 17, 2008 :

    My preference is to not prefix fields, and then avoid name clashes with parameters.

    Surely
    UpdateFooWith(newFooValue)
    {
    foo = newFooValue;
    }

    is clearer than

    UpdateFoo(foo)
    {
    this.m_foo = foo;
    }

    ?

  14. Shahar Y

    Said on July 17, 2008 :

    @David
    The problem is that you are not always aware of the name collision and when you use m_ you don’t need to use this.

  15. David Kemp

    Said on July 17, 2008 :

    @Shahar

    That’s what Resharper’s for!

  16. georgem

    Said on July 17, 2008 :

    @greg
    >The “this” prefix is better because you’re >using a compiler-enforced assertion that this >is a member of the class

    that’s the problem – it’s not enforced – you can easily forgot that “this” the compiler will swallow it happily. So in reality it results of mix of this-ed members and non-this-ed members.

    And I think, that it’s also quite difficult to maintain the name uniqueness in durable projects – problem is that e.g. when you derive from some class and some year later, some refactoring happens and someone adds a protected field to that base class with name that collides with some local variable of your function in derived class… Compiler will say nothing here and problems start to appear slowly… :-).

  17. Glenn

    Said on July 17, 2008 :

    What about public properties that get/set a private member variable of the same name (differing only in case)? VB is case-insensitive, so you can’t, for example, do this:

    Private name As String
    Public Property Name() As String
    Get
    Return name
    End Get
    Set(ByVal value As String)
    name = value
    End Set
    End Property

    You also can’t do this:

    Private name As String
    Public Property Name() As String
    Get
    Return Me.name
    End Get
    Set(ByVal value As String)
    name = value
    End Set
    End Property

    This works fine:

    Private m_name As String
    Public Property Name() As String
    Get
    ‘The “Me” is optional
    Return Me.m_name
    End Get
    Set(ByVal value As String)
    m_name = value
    End Set
    End Property

    Yes, you could rename the private member, but in some cases it seems “forced”. What would you rename “name” to? “nameField”? Ugh.

  18. Dave Amphlett

    Said on July 17, 2008 :

    I think we all experiment when we’re relatively new developers, but I’ve not met a ‘good’, experienced developers who doesn’t use either this. or an m_ or _ member prefix. Have your seat of the pants fun with your non-explicit variable usage. Get it out of your system. Ideally on non-critical apps! But if you’re still coding is an OO type safe language 10 years from now I reckon you’ll be doing it :)

    Personally I use the ‘_’ prefix, but have been known to use this. on projects that have that as an existing convention.

  19. Arjan Bosma

    Said on July 17, 2008 :

    If you must use the prefix ‘m_’ then by definition you also must use type prefixes consistently. They are also part of Hungarian notation after all. Not only must you do this for value types but also with reference types, for instance like m_lstElements for a list of elements. I feel that now it does quickly become cumbersome and confusing. Do I use ‘lst’ for both a list of type element A and B?
    What about constant variables? Do I use m_ with class specific constant variables or some form of m_cn m_cs contraption. My point is you cant just simply apply one rule and ignore the other but in this case anyone of sound mind is forced to do just that.

    I’m all in favour of applying generally excepted style conventions. Not just in one team but across the industry. In this case, there is an authority…Microsoft somewhat dictating the style rule. I don’t mind that. These tools that dictate the rules, make my code function better. I didn’t personally invent the m_ prefix and I dont see any good reason not using ‘this’. So why not adopt the rule?

  20. Glenn

    Said on July 17, 2008 :

    @Arjan

    I disagree that using the “m_” prefix necessitates using type prefixes. They’re not the same — type prefixes denote data types, while the “m_” prefix denotes scope.

    As for using “this.”, that’s fine in C#, a case-sensitive language. But what about properties in VB? You can’t return the private “Me.name” from a public property called “Name”.

  21. Arjan Bosma

    Said on July 17, 2008 :

    @Glenn

    I think you misread my post. My point is they are both part of a naming convention to which all rules apply. You cant just say m_ is better because of the Hungarian notation etc…and then completely ignore all the other rules in the naming convention.

    For the second part of your post I would say the same problem applies to C#. You can get away with using upper case for properties and lower case for fields but that’s just bad programming. I’m pretty sure that Style Cop (or FxCop) also dictates that prive member variables must be upper case for exactly that reason.
    The problem here however is not the naming convention but the fact that you dont want directly expose the field. Field and property have similar purpose hence the names clash.
    Going around things like that is always going to be sort of a glue and spit solution if you know what I mean.

  22. Arjan Bosma

    Said on July 17, 2008 :

    There is a language construct in C# 3.0 I was unaware of called auto-implemented properties. that deals with exactly this problem.

    See Microsoft MSDN: bb384054.aspx

    (url posting is blocked)

  23. mmp1

    Said on July 18, 2008 :

    I hear you brother!!! I personally love the m_ (member), l_ (local) and p_ (params). Why ? When you have to maintain code (written by someone else) it helps with the story. It DOES cut down on the number of bugs. When you are looking at maintaining commercial code (ie. for shrink wrapped) that has a long product lifecycle , it really makes a difference. Also, when using code generators it helps (ie. auto gen for getter/setters etc). I have used it for VB, Java, C/C++ (in C the g_ for global etc), ActionScript etc. Its one of those things that once you start, you don’t want to stop it. Thats why all the veterans (at least the guys I have worked with for the past 15 years) do it. The number one source of bugs in code is simple – lazy programmers, and things like this really , really help. I hear you brother.. go forth and preach.

  24. Jawed Ali

    Said on July 18, 2008 :

    I always use “this.” before using any class variable, also I don’t use duplicate variables other than getter/setter. And using underscores or hyphens is not that smooth in writing, unless you are a single finger typist. :D

  25. Anny

    Said on July 23, 2008 :

    > when I see a method implementation without m_ being used, I have to scroll around to find out where each variable came from Or you can hover over the variable name in VS to see “(parameter)…” in the tooltip. Or you can use ReSharper to get real code navigation.

  26. Gavin

    Said on July 24, 2008 :

    If you start your member variables with an uppercase letter it separates them from locals without the ugliness of a prefix.

    class Foo {
    private Bar;
    public Foo(string bar) {
    Bar = bar;
    }
    }

  27. ActionScribe

    Said on August 5, 2008 :

    I was on a team once that used “my” (member) and “a|an” (parameter) in their coding conventions. As I understand it, this is something that came out of Sun (my teammates were a bunch of Java-hippies, God bless them).

    I balked at it at first, but when I had to revisit some of our code a goodly long while later…

    class Foo {
    private myBar;
    public Foo(string aBar) {
    string prefix = “Hello, “;
    myBar = prefix + aBar;
    }
    }

    …was deliciously easy to follow, and very refreshing after looking at m_foos and this.bars for months in the interim.

  28. Laila

    Said on August 20, 2008 :

    The prefixes reduces readability of the code – the brain seeks to recognize a word without reading the whole word, just by identifying the look of it. Prefixes sabotage the brain and makes it read all the letters.

    Further, it sabotages many of the benefits of modern IDEs, particularly in Java. You have to correct generated (getters/setters) and intellisensed code. Color coding and highlighting also makes the prefixing completely superfluous.

    Even further, if you have two variables with the same name, they will usually serve different purposes. I say give them semantically meaningful names to distinguish their purpose, instead of some annoying prefix. This way all developers ever to enter your code will know what you mean.

    And as already pointed out by many, refactor the code to smaller methods if you have problems figuring out the variables. Prefixed code looks messy and takes so much longer to figure out simply because of the extra reading it causes.

  29. schneider

    Said on August 20, 2008 :

    The whole point is to distinguish class instance member variables from local method variables.

    There is no way to easily determine that, other than go to each declaration line, or hovering over the variable with the mouse to see the tooltip.
    It’s always easier to read the code.

    In most cases when I see it NOT done, there are many other problems besides this. Personally anyone working on my team is required to follow this practice; any arguments against it have little merit other than to wine against some minimal code standards that are easy to follow.

    Schneider

  30. richard swain

    Said on February 14, 2009 :

    The point of the prefix is to indicate ‘at a glance’ the scope of the variable. Hungarian types are banned because they don’t make sense
    in many modern computer languages. Types change. Scopes don’t.
    Using ‘this.’ as a scope identifier is flawed because it is possible to
    accidentally omit when writing code and once you come back to it, say because StyleCop has warned you, you have to then try to remember the intention if, as in some previous examples, it clashes with a local variable.

    Thus IMHO a prefix *any* agreed prefix is superior to using ‘this.’
    to indicate the scope of a variable. Even prefixing a class variable
    with ‘this’ such as in ‘thisMyVariable’ is better.

    I’m sorry I’m so hot under the collar about this issue but a member of our team has just issued a diktat that we should use the ‘this.’ approach to identifying scope and I don’t like it for the reasons given above.

Post a Comment