Geeks With Blogs
Path Notes of a Kodefu Master blog

Fields… not the kind with green grass and butterflies. Rather, fields that contain the deep dark secrets of a class. You know: member variables.

There’s plenty of divergence in naming these pieces of class data. Some developers prefix the field name with an underscore. Some prefer m (meaning member) and an underscore.  I personally prefer straight camelCasing. Here are some variations I’ve seen.

  1. private string name;
  2. private string _name;
  3. private string m_name;
  4. private string _Name;
  5. private string m_Name;
  6. private string mName;

There’s a lot of argument to be had concerning, and I was involved in a debate yesterday concerning this. A fellow developer in Greenville claimed that camelCasing was a bad practice because it confuses VB developers. He was advocating for PascalCased fields (and even regular variables / parameters… ::shudder::).

Here’s the deal. PascalCasing private member fields and variables is confusing to me as a C# developer. When I see PascalCasing, I assume that it’s part of the interface of the class. When I see camelCasing, I assume it’s private. Besides, I will

I find prefixing with an “m” rather bizarre. I believe this may be a holdover from some other language. I’ve heard the argument that it helps you differentiate between your members and local variables within a method. I would respond that underscore works just as well for that purpose, and your methods are too long if you couldn’t differentiate between the two.

This leaves underscore. I just think underscores are ugly. They are practical when a parameter name is the same as a field name, but I scope my variables in that situation which is the recommended practice anyway (e.g. = name).

Number 1 (camelCasing with no underscore) is the rule I’ve always followed because it felt most natural. But I can also say definitively that it is the accepted best C# styling practice. StyleCop rules SA1306 and SA1309 dictate that field names must begin with a lower case letter and must not begin with an underscore. For those that think “aha, m_ it is,” SA1310 states that field names must not contain an underscore.

The only time you should violate this rule when naming a field is when the field is not private. The only time your field should not be private is when it marked readonly. Be careful when doing this, as this will cause a change to your interface if you need to promote the field to a property. The only time I’ve seen a real use for this is with static readonly fields.

I’ve seen some people expose fields as protected. When this happens, it is important to remember that protected means the fields are public to derived classes. In other words, you have broken encapsulation. Encapsulate your fields as properties when you need to expose them anywhere outside of the class (except for static readonly fields, shorthand for “I need a const but need an instance in this context”).

That concludes my rant on fields. I’m sure some will disagree… feel free to voice your opinion in the comments. Keep in mind that unless your authority is greater than StyleCop (aka the styling authority of Microsoft), I will be hard to persuade. At the same time, I understand that different organizations adopt different styles for different reasons, and that’s find for your organization as long as you don’t start breaking framework guidelines as those affect consumers of your product.

Note: Cross posted from KodefuGuru.
Posted on Wednesday, August 5, 2009 11:25 AM | Back to top

Comments on this post: Fields in C#

# re: Fields in C#
Requesting Gravatar...
I am originally from South Africa where we used the normal camelcase standard for private fields. ie private bool hasHobbies;

I have since moved to the UK and every single company I have worked for so far uses _hasHobbies. I was reluctant to convert, but realised that the underscore is standard ethics in Resharper and kept my mouth shut.

Are you saying camel case is really the accepted standard?
Left by Marcel on Aug 07, 2009 3:58 AM

# re: Fields in C#
Requesting Gravatar...
Would this mean that private member fields and parameter fields both end up being camelCase?

e.g. like:

private string defaultExample;

private bool IsSomething(string anExample)
defaultExample = anExample;

This is why I prefer the _defaultExample for member fields, to differentiate between them and internal parameters and fields, but this doesn't seem to be accepted practice, we ended up writing custom stylecop rules to enforce those rules at my last company.
Left by Andrew Johns on Sep 09, 2010 5:51 PM

Your comment:
 (will show your gravatar)

Copyright © Chris Eargle | Powered by: