Dave Donaldson
Critical thinking in software development
Search
Advertisement
Subscribe
My Tweets
- @willburrus Haven't seen your email. Sorry, thought you would have seen mine earlier.
- @hkarthik I can't get my avatar to look quite like me. Need to spend more time with it I guess.
- Listening to new G 'N R album early on their MySpace page (http://www.myspace.com/gunsnroses). Still formulating an opinion.
- Follow Me on Twitter
Coding Guideline: DO Use an Underscore for Class Member Variables
Friday, November 09 2007
This post isn't meant to start one of those good-old-fashioned-programmer-holy-wars, but I think it's something that needs said: DO use an underscore when declaring class-level member variables.
I know some developers out there don't like to prefix class member variables (CMVs) because they think it's a holdover from a programming era long gone (maybe not *long* gone, but gone enough), but I firmly believe they should prefixed with an underscore. And to be clear, I'm NOT saying to prefix CMVs with m_, just _, as in _firstName. I agree that the practice of using m_ should be abandoned, but allow me to explain why I think using an underscore makes sense.
So let's setup some code. Below are two classes: PersonA (no underscore prefix) and PersonB (uses an underscore prefix):
| public class PersonA { private string firstName; private string lastName; private string middleName; private int age;
public string FirstName { get { return firstName; } set { firstName = value; } }
public string LastName { get { return lastName; } set { lastName = value; } }
public string MiddleName { get { return middleName; } set { middleName = value; } }
public int Age { get { return age; } set { age = value; } } } | public class PersonB { private string _firstName; private string _lastName; private string _middleName; private int _age;
public string FirstName { get { return _firstName; } set { _firstName = value; } }
public string LastName { get { return _lastName; } set { _lastName = value; } }
public string MiddleName { get { return _middleName; } set { _middleName = value; } }
public int Age { get { return _age; } set { _age = value; } } } |
The code is certainly simple enough, but the first thing I want to show is the difference in the Members dropdown list in Visual Studio, PersonA on the left and PersonB on the right:
 |  |
In PersonA the CMVs and the properties are intertwined together, while in PersonB the CMVs are grouped nicely at the top, thus allowing a clean separation between the CMVs and properties.
The next thing I want to show is the difference in the Locals debug window in Visual Studio, PersonA on the left and PersonB on the right:
 |  |
Look familiar? Like the Members dropdown list, there is a distinct separation between the CMVs and properties for PersonB, which I find is much easier on the eyes and allows the brain to distinguish between the two faster than how they are displayed in PersonA.
I suppose you could make an argument for using the this keyword in C# (or Me in VB) to distinguish CMVs from properties, but I've found that doing that a lot actually clutters things up. And clutter sucks. Plus, you still have the grouping issue I pointed out with the screenshots above. And speaking of VB, the PersonA class isn't even valid because of its case-insensitivity; it won't compile.
Here's the point I'm trying to make: when you see a variable prefixed with an underscore, you *immediately* know its scope and how it is declared. You don't have to hover over it or go to its definition to find out. You know at first glance without having to think about it. And that is what's important.
11 comment(s) so far
Then why even bring it up? :)
Seriously though, I see what you're saying about the sorting in VS, and that does make for a better experience. However, I just can't bring myself to type an extra character when I don't need to. Actually, that's not totally true because sometimes I do find myself using the 'this' keyword when I think it makes it my intent more obvious.
Hmm... maybe I need to rethink my stance on prefixes for member variables. At the very least it would help me avoid more accidental recursion.
I prefer the underscore when declaring class level member vars. Yea, the sorting is nice, but I also do it to avoid confusion - not necessarily for myself, but for others that may look at my code.
I tried using 'this' to distinguish between them (when NOT using an underscore), but I found that to be a pain.
Overall, while I agree with Dave, I also think it's one of those religious issues like whether or not you put the { on a separate line or not. ;-)
I like using the underscore too. Along with the sorting it lets me distinguish the member variables without having to type "this".
Personally, I don't think it matters as long as readability isn't lost and a team agrees on a standard.
I don't see the difference between m_ or _. They're both encodings.
What's the goal of the naming convention, better code readability (i.e. scope highlighting) or better IDE integration (or both)? I've always thought these were two separate issues. I usually ignore the IDE when choosing, but that's my preference.
FWIW, I use underscore for CMV's as well.
I have always used underscores, but your explaination is so much better than "That's what Martin Fowler does". lol.
This is definitely one of those coder religious issues. :)
Personally, I see the reason such as with the members drop down with debugger or intellisense, but I just can't stand the underscores. IMO, they take away from readability of the code. Just not a fan of them and shiver when I open a class littered with them. Better than camel case, but still don't like them.
Ken - I actually think using an underscore *improves* code readability because it's so explicit and as soon as your eyes see them your brain immediately knows what they are. If I see the variable firstName in a method (instead of _firstName), I have to think about how and where it was defined. Was it declared locally in the method or was it declared at the class level? Using an underscore eliminates that issue.
You bring up a good point. Not something new but I guess you illustrate it better than any other time I have heard the argument or maybe I am getting wiser in my old age and now see the light. Whatever it is I think I am going to start using this standard.
Thanks.
I think this should be solved by your IDE. VS should present its Intellisense box more appropriately.
I see your point, Dave. However, the addition of the "_" makes things a little hard to read.
Typically, it's not that much of an issue for me since I use R# to enhance my VS experience. So when creating a property for field "firstName", Ctrl R+E does the trick. I don't have to worry about it.
As far as then referencing the FirstName property, I guess I always type a "F" for it. I think if you were switching between C# and VB.NET it would make more of a sense to use the "_".
Since when should an IDE define coding style? It's immediately obvious whether or not a variable has been declared in the method you're reading. If it hasn't been, it's a class member, it's that simple.