Naming conventions for private members of .NET types [closed]

Question

Normally when I have a private field inside a class or a struct, I use camelCasing, so it would be obvious that it's indeed private when you see the name of it, but in some of my colleagues' C# code, I see that they use m_ mostly or sometimes _, like there is some sort of convention.

Aren't .NET naming conventions prevent you from using underscores for member names?

And when you mention the MS naming conventions or what not, they tell you theirs is the best way, but don't explain the reasoning behind it.

Also when I am the owner of some code, where I clearly use camelCasing for private members, when they have to make a minor modification to the code, they stick in their conventions instead of following whatever conventions are there.

Is this a controversy?

Answer 1

The .Net framework guidelines allow for a _ or m_ prefix on private field names because the provide no guidance on private fields. If you look at the BCL in reflector you'll notice a prefix is the most prevalent pattern.

The Reference page for naming fields is located here. Notice the guidelines only specify usage for public and protected fields. Private fields are simply not covered.

Answer 2

Technically, underscores are a violation of .NET conventions (or at least used to be -- see comment thread), but Microsoft programmers themselves often use underscores, and many examples in the documentation use underscores. I think it's very helpful to be able to see at a glance which variables are member variables (fields) and which are local. The underscore really helps with this. It also nicely separates private member variables from local variables in intellisense.

Please see this very useful page for .NET naming conventions:

http://10rem.net/articles/net-naming-conventions-and-programming-standards---best-practices

And here's a page with Microsoft's official recommendations:

https://msdn.microsoft.com/en-us/library/ms229045%28v=vs.110%29.aspx