In your.editorconfig file, you can define naming conventions for your .NET programming language code elements—such as classes, properties, and methods—and how the compiler or IDE should enforce those conventions. For example, you could specify that a public member that isn't capitalized should be treated as a compiler error, or that if a private field doesn't begin with an_, a build warning should be issued.

Specifically, you can define anaming rule, which consists of three parts:

• Thesymbol group that the rule applies to, for example, public members or private fields.
• Thenaming style to associate with the rule, for example, that the name must be capitalized or start with an underscore.
• The severity level of the message when code elements included in the symbol group don't follow the naming style.

General syntax

To define any of the above entities—a naming rule, symbol group, or naming style—set one or more properties using the following syntax:

<kind>.<entityName>.<propertyName> = <propertyValue>

All the property settings for a givenkind andentityName make up that specific entity definition.

Each property should only be set once, but some settings allow multiple, comma-separated values.

The order of the properties is not important.

<kind> values

<kind> specifies which kind of entity is being defined—naming rule, symbol group, or naming style—and must be one of the following:

<entityName>

<entityName> is a descriptive name you choose that associates multiple property settings into a single definition. For example, the following properties produce two symbol group definitions,interface andtypes, each of which has two properties set on it.

dotnet_naming_symbols.interface.applicable_kinds = interfacedotnet_naming_symbols.interface.applicable_accessibilities = public, internal, private, protected, protected_internal, private_protecteddotnet_naming_symbols.types.applicable_kinds = class, struct, interface, enum, delegatedotnet_naming_symbols.types.applicable_accessibilities = public, internal, private, protected, protected_internal, private_protected

<propertyName> and <propertyValue>

Each kind of entity—naming rule,symbol group, ornaming style—has its own supported properties, as described in the following sections.

Symbol group properties

You can set the following properties for symbol groups, to limit which symbols are included in the group. To specify multiple values for a single property, separate the values with a comma.

Notes:

1. Tuple members aren't currently supported inapplicable_kinds.
2. The symbol group matchesall the modifiers in therequired_modifiers property. If you omit this property, no specific modifiers are required for a match. This means a symbol's modifiers have no effect on whether or not this rule is applied.
3. If your group hasstatic orshared in therequired_modifiers property, the group will also includeconst symbols because they are implicitlystatic/Shared. However, if you don't want thestatic naming rule to apply toconst symbols, you can create a new naming rule with a symbol group ofconst. The new rule will take precedence according to therule order.
4. class includesC# records.

Naming style properties

A naming style defines the conventions you want to enforce with the rule. For example:

• Capitalize withPascalCase
• Starts withm_
• Ends with_g
• Separate words with__

You can set the following properties for a naming style:

Notes:

1. You must specify a capitalization style as part of your naming style, otherwise your naming style might be ignored.

Naming rule properties

All naming rule properties are required for a rule to take effect.

Notes:

1. Severity specification within a naming rule is only respected inside development IDEs, such as Visual Studio. This setting is not understood by the C# or VB compilers, hence not respected during build. To enforce naming style rules on build, you should instead set the severity by usingcode rule severity configuration. For more information, see thisGitHub issue.

Rule order

The order in which naming rules are defined in an EditorConfig file doesn't matter. The naming rules are automatically ordered according to the definitions of the rules themselves. More specific rules regarding accessibilities, modifiers, and symbols take precedence over less specific rules. If there's overlap between rules or if the rule ordering causes problems, you can break out the intersection of the two rules into a new rule that takes precedence over the broader rules from which it was derived. For examples, seeExample: Overlapping naming strategies andExample:const modifier includesstatic andreadonly.

Example: Overlapping naming strategies

Consider the following two naming rules:

1. Public methods are PascalCase.
2. Asynchronous methods end with"Async".

Forpublic async methods, it's not obvious which rule takes precedence. You can create a new rule forpublic async methods and specify the naming exactly.

Example:const modifier includesstatic andreadonly

Consider the following two naming rules:

1. Constant fields are PascalCase.
2. Non-publicstatic fields are s_camelCase.

Rule 2 is more specific and takes precedence, so all non-public constant fields are s_camelCase. To resolve the issue, you can define an intersection rule: non-public constant fields are PascalCase.

Default naming styles

If you don't specify any custom naming rules, the following default styles are used:

• For classes, structs, enumerations, properties, methods, and events with any accessibility, the default naming style is Pascal case.

• For interfaces with any accessibility, the default naming style is Pascal case with a required prefix ofI.

Code Rule ID:IDE1006 (Naming rule violation)

All naming options have rule IDIDE1006 and titleNaming rule violation. You can configure the severity of naming violations globally in an EditorConfig file with the following syntax:

dotnet_diagnostic.IDE1006.severity = <severity value>

The severity value must bewarning orerror to beenforced on build. For all possible severity values, seeseverity level.

Example: Public member capitalization

The following.editorconfig file contains a naming convention that specifies that public properties, methods, fields, events, and delegates that are markedreadonly must be capitalized. This naming convention specifies multiple kinds of symbol to apply the rule to, using a comma to separate the values.

[*.{cs,vb}]# Defining the 'public_symbols' symbol groupdotnet_naming_symbols.public_symbols.applicable_kinds           = property,method,field,event,delegatedotnet_naming_symbols.public_symbols.applicable_accessibilities = publicdotnet_naming_symbols.public_symbols.required_modifiers         = readonly# Defining the 'first_word_upper_case_style' naming styledotnet_naming_style.first_word_upper_case_style.capitalization = first_word_upper# Defining the 'public_members_must_be_capitalized' naming rule, by setting the# symbol group to the 'public symbols' symbol group,dotnet_naming_rule.public_members_must_be_capitalized.symbols  = public_symbols# setting the naming style to the 'first_word_upper_case_style' naming style,dotnet_naming_rule.public_members_must_be_capitalized.style    = first_word_upper_case_style# and setting the severity.dotnet_naming_rule.public_members_must_be_capitalized.severity = suggestion

Example: Private instance fields with underscore

This.editorconfig file snippet enforces that private instance fields should start with an_; if that convention is not followed, the IDE will treat it as a compiler error. Private static fields are ignored.

Because you can only define a symbol group based on the identifiers it has (for example,static orreadonly), and not by the identifiers it doesn't have (for example, an instance field because it doesn't havestatic), you need to define two naming rules:

1. All private fields—static or not—should have theunderscored naming style applied to them as a compilererror.
2. Private fields withstatic should have theunderscored naming style applied to them with a severity level ofnone; in other words, ignore this case.

[*.{cs,vb}]# Define the 'private_fields' symbol group:dotnet_naming_symbols.private_fields.applicable_kinds = fielddotnet_naming_symbols.private_fields.applicable_accessibilities = private# Define the 'private_static_fields' symbol groupdotnet_naming_symbols.private_static_fields.applicable_kinds = fielddotnet_naming_symbols.private_static_fields.applicable_accessibilities = privatedotnet_naming_symbols.private_static_fields.required_modifiers = static# Define the 'underscored' naming styledotnet_naming_style.underscored.capitalization = pascal_casedotnet_naming_style.underscored.required_prefix = _# Define the 'private_fields_underscored' naming ruledotnet_naming_rule.private_fields_underscored.symbols = private_fieldsdotnet_naming_rule.private_fields_underscored.style = underscoreddotnet_naming_rule.private_fields_underscored.severity = error# Define the 'private_static_fields_none' naming ruledotnet_naming_rule.private_static_fields_none.symbols = private_static_fieldsdotnet_naming_rule.private_static_fields_none.style = underscoreddotnet_naming_rule.private_static_fields_none.severity = none

This example also demonstrates that entity definitions can be reused. Theunderscored naming style is used by both theprivate_fields_underscored andprivate_static_fields_none naming rules.

See also

• Language rules
• Formatting rules
• Roslyn naming rules
• C# identifier naming rules and conventions