Version Used:
Not sure of Roslyn version, but using VS 15.5.3.
Description:
In the .editorconfig naming conventions described in the docs, symbols can be defined with applicable_kinds equal to class, struct, enum, etc. From my own testing, it appears that enumerated _types_ use the enum kind, while enumerated _values_ use the const kind. This can be frustrating, as shown in the code below. I asked about this on StackOverflow a while back, and nobody had a legitimate solution, so I figured I'd raise an Issue. If this is not the correct repo for .NET .editorconfig settings, please direct me to the correct one.
Consider the following .editorconfig (the more complete file that I use is available here):
# Require const fields to be all upper-case
dotnet_naming_symbols.const_fields.applicable_accessibilities = *
dotnet_naming_symbols.const_fields.required_modifiers = const
dotnet_naming_rule.const_fields.symbols = const_fields
dotnet_naming_rule.const_fields.style = all_upper
dotnet_naming_rule.const_fields.severity = warning
# Require enums to be Pascal case
dotnet_naming_symbols.enums.applicable_kinds = enum
dotnet_naming_rule.enums.symbols = enums
dotnet_naming_rule.enums.style = pascal_case
dotnet_naming_rule.enums.severity = warning
#Naming styles
dotnet_naming_style.all_upper.capitalization = all_upper
dotnet_naming_style.pascal_case.capitalization = pascal_case
and the following C# code. The in-line comments represent the warnings shown after "Naming rule violation:" in Visual Studio:
public class DerpClass {
public const int DERP = 5; // OKAY
public const int Derp = 5; // These words cannot contain lower case characters: Derp
}
public enum EnumLower {
val // These words cannot contain lower case characters: val
}
public enum EnumPascal {
Val // These words cannot contain lower case characters: Val
}
public enum EnumUpper {
VAL // OKAY
}
public enum derpenum { // These words must begin with upper case characters: derpenum
VAL
}
As you can see, the enums naming rule applies only to the _name_ of enum types, not to their values. Instead, enum values share the const_fields naming rule with const fields. This is frustrating, as I either have to make my enumerated values all-upper-case or make my const fields Pascal-case, neither of which follows typical naming conventions for a C-based language. But it's either that or deal with a million Naming rule violation warnings throughout my codebase (or Messages, if I change severity).
Since the enum applicable_kind value is clearly meant for enum _type_ names, similar to the class and struct kinds, it would be great if there were another applicable_kind for enumerated values, say enum_value. That way, enum types, enum values, and const fields could all have their own naming styles. If the Roslyn compiler really treats enum values as consts then I could see this being difficult to implement, but I know nothing of compiler design so hopefully it can be done!
Enum members should be separate from const fields, and probably have the applicable kind enum_member. This is related to #23336 and should probably be resolved at the same time.
@sharwell That issue is on the 15.7 milestone. Does that mean this issue will be added to it as well?
@sharwell I see that #23336 is now closed. Any reason this issue has been moved to Unknown?
@Rabadash8820 "Unknown" is a milestone for items we plan to address once someone sends a pull request but (in most cases) we haven't started on it yet. 馃槃
Lol k. I might poke around your commits on #23336 to see if I can implement this, but no promises.
Commit 10d8f1a is the main one you'll want to see. :smile:
@Rabadash8820 I'm curious whether you've tried your rules in VS 2019? I can't for the life of me get .editorconfig to apply any rules to enum members, period. Even if I copy your rules verbatim, I get no warnings at all regardless of how enum members are cased.
@irontoby I seem to be experiencing the same issue (VS 16.4.2). Since I opened this Issue, I now enforce an ALL_UPPER convention for private consts and a PascalCase convention for non-private consts, so I'm not sure which of either of those is being applied to my enum members. However, as you reported, I see _no_ squigglies at all on enum members when I make them all lowercase, so clearly something is broken. I basically just ignore the presence or absence of naming warnings around enums now though, due to this issue 馃し鈥嶁檪