C# Code Style in Visual Studio 2017

Olav Nybø

The Code Style options for C# in Visual Studio 2017 have improved a lot since Visual Studio 2015.

In Visual Studio 2015 there wasn't a lot of options to choose from, there were only 4 settings.

VS2015 Code style options


I don't think I ever changed any of them from their defaults.

The Visual Studio 2017 version of the same options has grown a lot as can be seen in the screenshot below.

VS2017 Code style options

We also note that formatting has moved unde Code Style and got some minor adjustements, but I think the new Naming section is quite interesting.

Using the Code Style Naming options we can configure Visual Studio to enforce our code style rules for naming of classes, interfaces, methods, properties, fields and others.
Visual Studio can provide hints or red squiggles if we break the naming rules which is nice I think, but the really great part of it is that the naming rules are followed by the code generation features of Visual Studio 2017.

Configure Naming Rules

If we click on the Naming section below Code Style we should see something similar to this:

A Naming rule consist of three parts:

  • specification
  • Required Style
  • Severity

The specification tells what code elements this rule should be applied to. In the example above we have rules for naming of Interfaces, Types etc.

The required style tells how the matched code element should be named. E.g. we have a rule that Interfaces should begin with a capital I.

The Severity is how Visual Studio should tells us that the rule is broken.

One thing that should be noted is that changes to the naming rules seem not to take effect for open files until they are changed or they are closed and reopened. It seems that the style checking must be nudged a bit to run.

See below for a short demo where I change the naming rule for interfaces to require the prefix "AI" and change the severity for this rule to "Error" so that I will get a red squiggle. Then I show that the "light bulb" will offer to fix the code according to my new rule.

animated gif demo of changing the interface naming rule

Interaction with code generation

The ability to automatically generate a field from a constructor parameter and set it in the constructor is a very nice feature that saves some keystrokes. But until I figured out the Naming rules it didn't quite do what I wanted. The default behavior is to just add the member with same name and prefix the member with "this." when setting the field in the constructor as shown here:

I prefer that fields are prefixed with an underscore. With naming rules this can be quite easily fixed by adding a rule for naming for field.

We need to create a specification that matches private fields, then we must have a rule that requires underscore prefix and then we add the rule.

A quick demo below (creating the underscore rule is similar to creating the specification so I just show that I have the rule in place).

Conclusion

Equivalent functionality to what I have described here and much more are available in addons such as Resharper. But I feel that Resharper has become big and bloated and I am happy to see that the experience using plain Visual Studio without any addons is improving.