EditorConfig Reference for C# Developers

04 Jul 2017

Preamble

If you’ve not heard of EditorConfig, it’s a platform- and language-agnostic format to describe coding styles. Take a look at the home page for more information.

Recently, the Roslyn/.NET team added support for EditorConfig to Visual Studio. Consequently, one can simply drop an .editorconfig file alongside one’s solution and have Visual Studio automatically point out any style problems in your code. Configuration is hierarchical, too, so if you place another .editorconfig within a subfolder of your solution, those rules will apply therein, overriding any rules applied at a higher level.

Whilst this is an awesome direction to be taking the platform, there are several problems.

Firstly, there is no solid documentation around the C# (and .NET) configuration options that .editorconfig supports inside Visual Studio. There is scattered information out there, including this promising looking page. However, none of it is complete, and most of it is code rather than documentation.

Secondly, the tooling does not integrate with the compiler as yet. That is, an error will be displayed where relevant, but it won’t break your build. This is acknowledged by the Roslyn team, and is something that will be addressed by them in the near future.

Thirdly - and this is my opinion - the implementation does not yet offer sufficient control over style. Even with the strictest .editorconfig in place, it’s still possible for project collaborators to produce code with wildly inconsistent styling. Partly this is due to options that are missing altogether, and partly it’s because some options are present but do not support enforcement via code style options (discussed below). This is unfortunate and is unlikely to ever be fully addressed, but I hope the Roslyn team continue to flesh out the available styling options. In the meantime, something is better than nothing in my book.

This blog post seeks to address the first problem only.

Note that I have uploaded a sample .editorconfig file to GitHub. This file contains every option key listed within this blog post, assigning values that I like to use by default. However, the intention is to make it easy for other developers to use as a starting point when constructing their .editorconfig files.

Reference

Following is a list of all supported options in alphabetical order. For each option, I list the key, valid values, and example code showing the effect of different settings (note that I have elided sample code when it is not possible to visually portray the effect, such as with whitespace settings). In addition, an indication is given as to whether code style options are supported for that particular key. If code style options are supported, that means the assigned value should be suffixed with a colon (:) and then an indication of what should happen when violations are detected. Valid suffixes are:

none : ignore violations, but use the specified value when generating code

suggestion : violations result only in a suggestion being made to the programmer (via dots under the first two characters of the violation)

dotnet_naming_*

The dotnet_naming_* options are a special set of options that work somewhat differently to other options. They allow you to construct naming conventions in quite a flexible manner, though there are some annoying limitations (like not being able to stipulate no prefix be allowed). However, only parts of the keys are fixed. Other parts you are free to name in whichever way you choose, allowing you to construct any number of naming rules. Here is an example: