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.

1. Add a new style.
2. Specify a title for the style (i.e. “Begins with _ and camel cased”).
3. Set Required Prefix to _.
4. Set Capitalization to camel Case Name.
5. 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.

1. Add a new specification.
2. Specify a title for the specification (i.e. Static Class).
3. Set Symbol Kind to only class.
4. Clear all values in Accessibilities.
5. Set Modifiers to only static.
6. 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.

1. Click the plus button to add a new rule.
2. Set the Specification element to the existing specification Private or Internal Field.
3. Set the Style element to the style created earlier (i.e. Begins with _ and camel cased).
4. 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.