Review naming recommendation for fields

[Keboo]

Right now our naming standard (Underscore + CamelCase) differs from the more common (Underscore + PascalCase).
Following our guideline is now getting flagged in Visual Studio due to new .editconfig defaults.
https://learn.microsoft.com/dotnet/fundamentals/code-analysis/style-rules/naming-rules#rule-id-ide1006-naming-rule-violation

This can be mitigated by adjusting your editorconfig, but requires someone making a change from the default.

[ascott18]

Isn't our current standard Underscore + PascalCase? Not Underscore + CamelCase?

[ascott18]

cc @GrantErickson @mitch-rickman

[MarkMichaelis]

After discussion, @Keboo and I agree on the following:
This essentially comes down to whether the advantages of _ outweigh the convention/tradition of _.
Recommendation:
State the pros and cons of _ _ case and then leave it to the developer (team) to choose.
In our coding guidelines (which currently only allow for a one-sentence guideline with no explanation), remove the guideline entirely.

Thoughts?

[Keboo]

I think I would change the guidelines to be something like:
DO: Name all fields consistently, regardless of any field modifiers.

Specifically looking to call out that we don't think separating naming of things like static, readonly, public, private etc is beneficial.

[MarkMichaelis]

Isn't that true for all naming conventions... not just fields?

[Keboo]

It is, however, fields naming based on modifiers is an area with lots of conflicting information online (including some MS docs) so it may be worth calling out.