Editorconfig integration with Visual Studio and .NET
If you are not familiar with EditorConfig files, you’re missing out
Today, I’ll walk you through some of the basic features, as well as some extensions to the format supported by Visual Studio and the .NET tools.
The basics
Editorconfig is a way to define some coding styles by adding files called .editorconfig
to your code repository.
There’s pretty wide support from editors out there that supports it either natively, like Visual Studio, or through add-ons, like Visual Studio Code.
Hierarchy
Editorconfig us a hierarchical configuration for code style, meaning that when a code file is open, it will apply every settings from .editorconfig
files it finds, from the file’s folder, up to the root of the file system.
The closer to the code file the config is, the higher the priority.
You can make prevent scanning parent directories by specifying root = true
in your .editorconfig file
.
Syntax
Editorconfig files are split into sections. Each section starts with a file selector, as determined by square brackets []
.
This selector can apply to every file like [*]
, a simple wildcard like [*.json]
, or a list of extensions like [*.{cs, vb}]
Consider the following example:
root = true
[*]
indent_style = space
[*.{cs,vb}]
indent_size = 4
insert_final_newline = true
charset = utf-8-bom
First, we have root = true
, meaning that we won’t be scanning any parent folders for more .editorconfig
files.
Then, we have a [*]
block that applies to every file, saying we will be using space to indent.
And last, we have the [*.{cs,vb}]
block that will apply to all files with a .cs
or .vb
extension.
Those files will have a indent of 4 (using spaces since the content of the [*]
block is still being applied), we want to ensure the presence of an empty line at the end of each file, and we are using the UTF-8 character set with the byte order mark.
Tip: If using git, you will want to make sure that your gitattribute don’t conflict with your .editorconfig
settings, otherwise your editor might trying to undo what git is doing on checkout, causing a bunch of changes that aren’t wanted.
.NET specific extensions
With the Roslyn compiler, there’s a number of extensions to the Editorconfig format that allows to configure code analysis.
For example, you can use Editorconfig to tell whether using clauses should be sorted with the System
namespace first
[*.{cs,vb}]
dotnet_sort_system_directives_first = true
You want contributors to use var
for C# built-in types? Done!
csharp_style_var_for_built_in_types = true
You can even make it an error:
csharp_style_var_for_built_in_types = true:error
You can also configure casing, as well as prefix and suffix. This will give a warning for any fields that are not camel case, and not prefixed with an underscore _
.
dotnet_naming_rule.instance_fields_should_be_camel_case.severity = warning
dotnet_naming_rule.instance_fields_should_be_camel_case.symbols = instance_fields
dotnet_naming_rule.instance_fields_should_be_camel_case.style = instance_field_style
dotnet_naming_symbols.instance_fields.applicable_kinds = field
dotnet_naming_style.instance_field_style.capitalization = camel_case
dotnet_naming_style.instance_field_style.required_prefix = _
See the official documentation for more options. The [Roslyn .editorconfig] also has number of good examples.
Configuring code analysis
If you’re familiar with Visual Studio and Code Analysis, you might have had to configure it through xml via .ruleset files.
That’s no longer necessary, as it can be done through Editorconfig!
All you need is a line that reads dotnet_diagnostic.<Code>.severity = <Severity>
, such as:
[*.{cs,vb}]
dotnet_diagnostic.RCS1007.severity = error
Conclusion
Whenever you a small or a large team, having common code styles in your project can help minimize head scratching when reading a teammate’s code (or let’s be honest, your past self’s code as well). With Editorconfig, you have a standard way that’s not tied to specific technologies to help make those styling standard happens.
What coding styles do you apply to your project?