Yesterday I started revisiting coding standards and read a nice post recently C# coding standards for private member variables? by Omar Shahine, and I wanted to respond with my own thoughts but I realised quite quickly that I am going to need a couple of things first, namely a can opener, a can of worms and to go right back to first principles.

Why use Hungarian/Pascal case/Camel case etc?

This has a simple answer, we want to differentiate between some aspect of our code.

Good use of Hungarian notation means that even with a fragment of code printed on paper, you can still tell an identifiers type. If you follow the MS guidelines you will find that you can always tell scope. So what we really ask with this question is...

What should using a naming standard give us?

Now before I give my opinion on this, I will also state what I think people have got so emotional about using there own standards. With a modern IDE, naming standards don't matter. All you need is to hover and you can have namespace, type, scope, XMLDoc comments. With a quick press of F12 (or right-click, Goto Definition) then you can zoom to see exactly how and when something is declared. VS2005 brings Find all references showing exactly how something is used for its entire lifespan. So what does a naming standard give us?

Consistency

We can all look at the same fragment of code and make the same assumptions. This is probably the most important thing that we are trying to acheive, however it doesn't actually tell you anything special.

Type

The Hungarian Notation Camp. What happens when your design requires you to subclass an object? Should you change the name, everywhere in the code? What do you name it if you are binding to base class, but only looking for one of the derivations?

Hungarian is great if you reading code fragments on paper, but I personally believe it gets the way of productivity in a modern IDE. All you need to do is to change the type of a member and you have to rename every reference to it. While the IDE can find you all those references (and some even rename all those references) wouldn't it make sense not to have to go through this. A userID is still a userID, but an intUserID needs work to become a strUserID.

Scope

This is what Microsoft have opted for in there current standards for objects that are Publically/Globally referable to, in some ways Standards between interfaces. However they have left the private/protected member variables open to user interpretation.

There is an advantage to identifying the private/protected members too that can be best explained with an example.

Say you have an object Process which performs a simple Task, and has a LastRun DateTime and a LastStatus. Now if we run the Process so that our LastRun and LastStatus change, the what we expext to happen if we change our Task to be a different task. Should the LastRun and LastStatus clear? In this example then we now expect our LastStatus to be Ready, not Complete or Error.

If we change our Task with a property, then the set accessor has the chance to reset the Status. However if as a developer, I could use the private member that stores Task, I will leave the Status unchanged. So if we use a naming standard to identify the private/protected members then we are issuing a warning that you should be using the property instead of the field.

IMHO

I am in favour of indentifying scope and using it as a warning that a private/protected member field could be better modified by using a Property. I do however have the following reservations.

• What happens when you have a protected property for a private field? They can't both have the same name.
• It's a warning that doesn't always need to be checked. Will this make me lazy?

So what should I use?