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 Tools\Options
then Text Editor\C#\Code Style
. Within the list of options are a variety of standard rules that most developers will want including
- Use of
this
keyword before members - Use of
var
keyword 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.
Managing Styles
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”).
- Set
Required Prefix
to _. - Set
Capitalization
tocamel 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.
Managing Specifications
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).
- Set
Symbol Kind
to onlyclass
. - Clear all values in
Accessibilities
. - Set
Modifiers
to onlystatic
. - 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
Specification
element to the existing specificationPrivate or Internal Field
. - Set the
Style
element to the style created earlier (i.e.Begins with _ and camel cased
). - Set the
Severity
element 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.