Today, is a memorable day for me. This morning I had to bite the bullet: get rid of my Hungarian Coding style in C#. Not because I hate Hungarian Coding, on the contrary: I love it, but because I have to. The reason for this is that when you want to sell a library which targets .NET, you simply can't feed your customers a library with interfaces which use input parameters like cmdCommandToExecute or efEntityField. I did convince myself when I started this project, it was my code and I should decide how the interfaces looked like. But this is just plain stubbornness. A customer doesn't give a you-know-what about the zillion + 1 reasons you can bring to the table why you had to make the interfaces of the classes inconsistent with the rest of the classes used in the application (f.e. the .NET classes).
Does it hurt? Well, a little. I'm still convinced Hungarian Coding is necessary. F.e. I had an input parameter 'iOperator'. You can't change that to 'operator' because that's a reserved keyword. So you have to come up with another name for a parameter that's perfectly described with 'operator'. Member prefixing is another advantage, however you can also have that with your caMel cased members, f.e. by using a '_' prefix. Microsoft avoided every guideline for private member variable naming, and if I have to guess I think the reason for this is that with a prefix you can use the same name for a member and a parameter which supplies the value for the member in a constructor or method, without forcing you to come up with 2 names for the same value.
I'll miss it though, as I missed my own scheme when I switched to Hungarian Coding back in 1995 (doing C++ work is driving you towards Hungarian Coding, like C# is driving you to PasCal /caMel casing). I already fear the Cold Turkey syndrome I expect when I re-read my own code without a type prefix in sight. *iShiver*