Discussion Use camel casing when naming private or internal fields, and prefix them with _. !!

OK I just noticed Microsoft updated their docs about C# naming convention and the underscore appeared!!

"Use camel casing ("camelCasing") when naming private or internal fields, and prefix them with _."

https://docs.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions

I am sure this was never there and indeed at least 1 complaint flooded in! Until the thread was locked as too heated!!
https://github.com/dotnet/docs/issues/25754


Is this Microsoft losing its way or were underscores always the way and I just missed the boat?!

In visual studio if you turn an auto property into a full property it has no _ on the private member!

 

It was changed in 2021, as was "s_" for static and "t_" for thread-static. It's a headache for a lot of organizations with large existing codebases that mandate full compliance. Plus it's just not as readable, at least to me.

 

FFS - why Microsoft...? I missed this. I will pretend it never happened... I think Visual Studio is ignoring it...

 

Visual Studio is from Microsoft...

 

Also who cares? As with all projects, just use the casing that is determined internally. Sometimes I use camel case, sometimes I use snake case, sometimes I even use pascal case. This is beyond a non-issue.

 

I have been using the underscore prefix for years. Really runs home whether you're dealing with a class field vs a local variable.

Unity uses a lot of m_ prefixing for fields which is understandable given that the core engine is written in C++.

PS: if you read the first comment in that issue you'd know that MS has been using this naming convention internally for a long time.

Also, read this comment: https://github.com/dotnet/docs/issues/25754#issuecomment-903813841

 

Maybe the idea was to unify some conventions with JavaScript and others to make it easier to switch from one language to another.

 

This is an interesting discussion. I don't use the underscore for my private variables but I've seen it plenty so it doesn't surprise me that it is being used and recommended via that doc. The specific comment CodeSmile linked too also gives some good reasons why the underscore still makes sense, though I'm still not currently doing it. I may change at some point.

In any case, it really doesn't matter, consistency is what matters, and the commenter specifically said that as well.

 

So Visual Studio has built in naming rule violation checks, but just does camelCase vs PascalCase by default it seems (at least in Community).
Do you need an extension or custom rule set to actually force all the naming rules?

(yes this is not the end of the world, but companies sticking to microsoft rules will huff & puff)

 

You can ignore that. It is like PEP8 in Python. It is your codebase, you can do whatever with it, you don't have to adhere to this convention.


The thing is, names starting with an underscore are supposed to be reserved in C++, so in C++, using "_name" is frowned upon, but this is not the case in C#. On other hand, there's not enough cases to distinguish property and field used by the property, so the suggestion sort of makes sense, as you already end up with something simialr in many cases.

Code (csharp):

1.  
2. public class Blah{
3.     public int blah => _blah;
4.     int _blah = 0;
5. }
6.  

One thing that irritates me about MS convention is that they capitalize method names, while I'm more in favor of appraoch where only type names start with a capital letter.