Code-style naming rules

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 a naming rule, which consists of three parts:

• The symbol group that the rule applies to, for example, public members or private fields.
• The naming 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 given kind and entityName 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 and types, each of which has two properties set on it.

dotnet_naming_symbols.interface.applicable_kinds = interface
dotnet_naming_symbols.interface.applicable_accessibilities = public, internal, private, protected, protected_internal, private_protected

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

<propertyName> and <propertyValue>

Each kind of entity—naming rule, symbol group, or naming 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 in applicable_kinds.
2. The symbol group matches all the modifiers in the required_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 has static or shared in the required_modifiers property, the group will also include const symbols because they are implicitly static/Shared. However, if you don't want the static naming rule to apply to const symbols, you can create a new naming rule with a symbol group of const. The new rule will take precedence according to the rule order.
4. class includes C# records.

Naming style properties

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

• Capitalize with PascalCase
• Starts with m_
• 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 using code rule severity configuration. For more information, see this GitHub 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, see Example: Overlapping naming strategies and Example: const modifier includes static and readonly.

The EditorConfig Language Service extension can analyze an EditorConfig file and report cases where the rule ordering in the file is different to what the compiler will use at run time.

Example: Overlapping naming strategies

Consider the following two naming rules:

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

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

Example: const modifier includes static and readonly

Consider the following two naming rules:

1. Constant fields are PascalCase.
2. Non-public static 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 of I.

Code Rule ID: IDE1006 (Naming rule violation)

All naming options have rule ID IDE1006 and title Naming 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 be warning or error to be enforced on build. For all possible severity values, see severity 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 marked readonly 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 group
dotnet_naming_symbols.public_symbols.applicable_kinds           = property,method,field,event,delegate
dotnet_naming_symbols.public_symbols.applicable_accessibilities = public
dotnet_naming_symbols.public_symbols.required_modifiers         = readonly

# Defining the 'first_word_upper_case_style' naming style
dotnet_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 or readonly), and not by the identifiers it doesn't have (for example, an instance field because it doesn't have static), you need to define two naming rules:

1. All private fields— static or not—should have the underscored naming style applied to them as a compiler error.
2. Private fields with static should have the underscored naming style applied to them with a severity level of none; in other words, ignore this case.

[*.{cs,vb}]

# Define the 'private_fields' symbol group:
dotnet_naming_symbols.private_fields.applicable_kinds = field
dotnet_naming_symbols.private_fields.applicable_accessibilities = private

# Define the 'private_static_fields' symbol group
dotnet_naming_symbols.private_static_fields.applicable_kinds = field
dotnet_naming_symbols.private_static_fields.applicable_accessibilities = private
dotnet_naming_symbols.private_static_fields.required_modifiers = static

# Define the 'underscored' naming style
dotnet_naming_style.underscored.capitalization = pascal_case
dotnet_naming_style.underscored.required_prefix = _

# Define the 'private_fields_underscored' naming rule
dotnet_naming_rule.private_fields_underscored.symbols = private_fields
dotnet_naming_rule.private_fields_underscored.style = underscored
dotnet_naming_rule.private_fields_underscored.severity = error

# Define the 'private_static_fields_none' naming rule
dotnet_naming_rule.private_static_fields_none.symbols = private_static_fields
dotnet_naming_rule.private_static_fields_none.style = underscored
dotnet_naming_rule.private_static_fields_none.severity = none

This example also demonstrates that entity definitions can be reused. The underscored naming style is used by both the private_fields_underscored and private_static_fields_none naming rules.

See also

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