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…
By Michael Campbell on Jul 16, 2008 | Reply
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.
By Greg Beech on Jul 16, 2008 | Reply
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_”.
By Shahar Y on Jul 16, 2008 | Reply
@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…
By Greg Beech on Jul 16, 2008 | Reply
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?
By David Seiler on Jul 16, 2008 | Reply
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.
By Ian Suttle on Jul 16, 2008 | Reply
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.
By Niki on Jul 16, 2008 | Reply
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.
By Schneider on Jul 16, 2008 | Reply
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!
By Shahar Y on Jul 16, 2008 | Reply
@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.
By Greg Beech on Jul 16, 2008 | Reply
@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?
By Dmitry on Jul 16, 2008 | Reply
What about static variables?
By Dave Bauman on Jul 17, 2008 | Reply
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.
By David Kemp on Jul 17, 2008 | Reply
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;
}
?
By Shahar Y on Jul 17, 2008 | Reply
@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.
By David Kemp on Jul 17, 2008 | Reply
@Shahar
That’s what Resharper’s for!
By georgem on Jul 17, 2008 | Reply
@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… :-).
By Glenn on Jul 17, 2008 | Reply
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.
By Dave Amphlett on Jul 17, 2008 | Reply
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.
By Arjan Bosma on Jul 17, 2008 | Reply
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?
By Glenn on Jul 17, 2008 | Reply
@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”.
By Arjan Bosma on Jul 17, 2008 | Reply
@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.
By Arjan Bosma on Jul 17, 2008 | Reply
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)
By mmp1 on Jul 18, 2008 | Reply
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.
By Jawed Ali on Jul 18, 2008 | Reply
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.
By Anny on Jul 23, 2008 | Reply
> 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.
By Gavin on Jul 24, 2008 | Reply
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;
}
}
By ActionScribe on Aug 5, 2008 | Reply
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.