Repository navigation
Review naming recommendation for fields #249
Description
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.
Activity
ascott18 commentedon May 13, 2023
Isn't our current standard Underscore + PascalCase? Not Underscore + CamelCase?
ascott18 commentedon Jul 17, 2023
cc @GrantErickson @mitch-rickman
MarkMichaelis commentedon Jan 16, 2024
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 commentedon Jan 16, 2024
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 commentedon Jan 16, 2024
Isn't that true for all naming conventions... not just fields?
Keboo commentedon Jan 16, 2024
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.