<codeslinger>

Eric Gunnerson recently blogged about field naming conventions. This is something I've been meaning to write about for a while. Observing that his post is generating comments means that I'm not the only one who thinks about this issue and inspires me to give my opinion on the matter.

I used to do a lot of development work in Delphi (invented by Anders Hejlsberg). During my Delphi days I adopted the popular convention of prefixing field names with the letter f (for example, fMyField). The letter f is supposedly short for field, just as in C++ the m_ prefix is short for member. When I moved over to working with C# (also invented by Anders Hejlsberg), I read Microsoft's Field Usage Guidlines, which recommend against Hungarian notation and prefixing when naming fields. I never liked Hungarian notation so I had no problems dropping it like a bad habit. I tried abandoning the use of a prefix for a while as well, but found it not as productive for the following reasons.

It is common to have a public or protected property whose backing store is a simple field of the same type. In this case, and under Microsoft's guidelines, the property name and field name only differ in case, with the former being Pascal case and the latter being camel case. With IntelliSense or CodeCompletion working for you, it is easier to accidentally insert the field identifier in place of the property identifier or vice versa. This can cause compiler errors if the property is read-only and you are assigning to it when you intended to assign to the field. It can cause runtime lockups or stack overflows due to infinite recursion if the property identifier is used in place of the field identifier in the body of the property's getter or setter. Yes these are uncommon occurrences, but once is enough for me. At a bare minimum, when reading code one must pay special attention to differentiate between identifiers that differ only by the case of their first letter.

Naming collisions can arise between fields and method parameters when both use camel case as Microsoft recommends. The solution is to qualify the field with the this keyword (as in this.myField = myField). The problem is that the compiler won't complain if you don't properly qualify the field name. I like having the compiler work for me to help catch logic errors such as this.

That leaves me with using prefixes. Eric points out that the C++ member convention (m_myField) or the leading underscore convention (_myField) are two popular choices among C# developers. And then there's the much more rarely used f*. Which should I choose? The first is three keystrokes and the second is two keystrokes, counting the Shift key. I'd rather just quickly type f, which is readily available at the left index finger, than have to use two pinky finger key presses off the home row to type an underscore. That, and I feel that there is a certain aesthetic advantage to not using underscores, which as Eric also points out, feels more hacky (my words, not his).

An example is probably in order:

class MyObject
{
	public MyObject(int objectID)
	{
		fObjectID = objectID;
	}

	public int ObjectID
	{
		get
		{
			return fObjectID;
		}
		set
		{
			fObjectID = value;
		}
	}

	private int fObjectID;
}

* I have actually seen f in use in some open source C# code, so I'm not the only crazy out there! Had I not seen that, I probably would have abandoned f in favor of the more conventional prefixes.