.NET – Why Microsoft Uses Same Naming Convention for Parameters, Variables, and Fields

coding-standardsnamingnet

I asked this question quite some time ago: How do you name your private variables in C#?

In one of the answers, I was pointed to Microsoft's MSDN page that shows that private variables/fields should be named like this:

private int myInteger;

But a parameter would be:

void SomeMethod(int myInteger)

and a local variable would be like this:

int myInteger;

So when you reference them like this

myInteger = 10;

you have no way of knowing which one you are talking about.

I am now starting a new project and one of my co-workers is asking me why we don't do something to differentiate at least some of these.

I am wondering the same thing. Why didn't Microsoft's standard keep these different?

Best Answer

The original naming conventions had a m_ prefix for class members, this got reduced down to simple an underscore. You'll see a lot of older C# Microsoft code using an underscore prefix. However, I heard in a Tech Ed once that a leading underscore is not CLS compliant. I assume this is the reason why they moved to the simpler one-name-fits-all scheme. It used to be (not sure now) that VB.Net's case insensitive names were also not CLS compliant.

For what its worth, I still use the leading underscore for class members. Even though you can disambiguate using this (this.name as opposed to name), bugs still get through.

You do not have to do everything that MS tells you to do.

Related Topic