In visual studio private variables have no _

[andypoly]

You say here about using underscore on private and internal members (despite some dispute over the history of this).
Yet Visual Studio Community 2022 will not put an _ on private variables by default and converting an auto property to a full one with private member will simply use a lower case private variable as one would expect, but contrary to the tips here.

Is there a disconnect between Visual Studio team and the docs team here?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 40f42506-f4a5-859a-0266-ded002056d83
• Version Independent ID: f940f2ad-e13d-4d37-6439-f8afcbc4e4c7
• Content: C# Coding Conventions
• Content Source: docs/csharp/fundamentals/coding-style/coding-conventions.md
• Product: dotnet-csharp
• Technology: csharp-fundamentals
• GitHub Login: @BillWagner
• Microsoft Alias: wiwagn

---

Associated WorkItem - 123086

[Youssef1313]

See dotnet/roslyn#44699

[Youssef1313]

Tagging @CyrusNajmabadi @sharwell to consider if Roslyn can/should change the default naming styles to match conventions.

[andypoly]

hmm - yeah why would Microsoft's Visual Studio not have an option to enforce the naming convention they suggest for their language... without an editor config change...

[CyrusNajmabadi]

Dotnet naming in no way represents the naming for the industry. Last time we looked (admittedly a few years back), camel cased variables was the norm. It wasn't even close. Personally, I think dotnet naming is super silly and literally how against our guidance around unnecessary sigils on identifiers. So I find it unlikely we would change here for this niche audience. If you want this naming convention, just specify it.

[BillWagner]

This is an area we should look at more holistically.

In general, our docs follow the dotnet/runtime coding style. We should update these articles to match that, and point liberally to the editorconfig section of the Visual Studio docs to enable each team to enforce their preferences.

[andypoly]

Dotnet naming in no way represents the naming for the industry. Last time we looked (admittedly a few years back), camel cased variables was the norm. It wasn't even close. Personally, I think dotnet naming is super silly and literally how against our guidance around unnecessary sigils on identifiers. So I find it unlikely we would change here for this niche audience. If you want this naming convention, just specify it.

Actually my preferred solution is for Microsoft to drop their silly 2021 decision to bring in all the _ s_ t_ dotnet stuff, but bit late now! I don't want to use it, but many teams will want to follow the documented style.

[CyrusNajmabadi]

Also, i have no issue with us shipping some sort of '.net naming' style that people could choose. Or an easy way to add all the right naming styles to an existing editorconfig.

I would just push back on any sort of step that made this the default for everyone if they moved to a new version of VS. This needs to be something people can opt-into, not something they're forced into that they need to opt-out of.

Thanks!