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. this.name = 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.