Custom Naming Styles in Visual Studio 2017
One of the great new features in Visual Studio 2017 is the ability to define naming rules for code and then let the IDE notify you when they are violated. Depending upon what options you choose the IDE can suggestion, warn or flat out fail compilation because of violations. In this release the options are limited but since the rules are using Roslyn, the options can only improve in later releases.
Common Style Rules
Let’s start by looking at the pre-defined rules. Go to
Text Editor\C#\Code Style. Within the list of options are a variety of standard rules that most developers will want including
- Use of
thiskeyword before members
- Use of
varkeyword instead of an explicit type
- Use of alias or formal type names for primitives
In each case you can select your preference and the severity of the rule. Severity can range from a suggestion to an error. At this time, violating these rules results in the appropriate message in the
Error List but it will not prevent compilation. This may change later.
If you go to the
Naming section you can see some common naming styles pre-defined. These include rules like
- Interfaces must begin with “I”
- Types should be Pascal cased
Naming rules allow you to specify the specification the rule applies to, the style rule to apply and the severity.
Style rules allow you some basic conditions that you want to enforce. Clicking the
Manage Style button allows you to edit the existing or add new rules. At a minimum you need to give the rule a name. Currently, as of RC 1, you can also define the following.
- Required prefix
- Required suffix
- Casing rules – camel, Pascal, etc.
As an example we can create a common style that specifies a member must be prefixed by an underscore and camel cased.
- Add a new style.
- Specify a title for the style (i.e. “Begins with _ and camel cased”).
Required Prefixto _.
camel Case Name.
- Click OK to save the style.
Create another style that specifies a member must be prefixed by an
s_ and camel cased for static fields.
If you click the
Manage Specifications button you can see the list of pre-defined specifications, or rules. These rules are based upon Roslyn and support things like classes, structs, and private methods. You can edit the existing specifications or create your own. When creating a specification you can define the kinds of symbol(s) that the specification applies to, the supported accessibility modifiers and any modifiers related to lifetime (i.e. abstract, static, etc.). This allows you to set up specific specifications based upon your needs.
As an example we can create a specification for static classes.
- Add a new specification.
- Specify a title for the specification (i.e. Static Class).
Symbol Kindto only
- Clear all values in
- Click OK to save it.
Creating New Name Rules
By combining specifications with styles you can create new rules that work like the existing ones. As an example, many developers like to prefix their fields with underscores and camel cased, like the style we created earlier. To add a new naming rule do the following.
- Click the plus button to add a new rule.
- Set the
Specificationelement to the existing specification
Private or Internal Field.
- Set the
Styleelement to the style created earlier (i.e.
Begins with _ and camel cased).
- Set the
Severityelement to the severity you want to use.
Create another rule for the
Private or Internal Static Field that uses the second style created earlier. You can create additional rules as needed.
Rules are applied in the order they appear. To ensure that one rule is applied before another use the arrows to move the higher priority rule up and the lower priority rule down.
Test the rules by creating code that violates the rules you created and then verify they appear in
Error List. Hopefully this feature will evolve in later updates and releases to allow us to create more complex rules without the need for writing an extension.