Tabs or spaces? Should tabs and indents be four spaces or eight? Should trailing whitespaces be trimmed? These are a few of the issues that coding styles address. And although every software development organization should establish a coding style, getting developers to follow one can be difficult. Fortunately, Visual Studio 2017 includes a feature called EditorConfig that makes this much easier.

EditorConfig enables you to control editor behavior related to coding styles by simply adding some settings to a text file and adding that file to Visual Studio projects or solutions. EditorConfig settings override user-level settings for the Visual Studio editor, enabling you to enforce a coding style across projects, solutions, and machines. EditorConfig can support multiple coding styles and multiple languages, even within a single project.

This feature started as an extension for previous versions of Visual Studio, but Microsoft incorporated it as a native feature in Visual Studio 2017. To use it in Visual Studio 2017, simply create a text file with the name .editorconfig, specify EditorConfig settings in the file, and add the file to Visual Studio projects or solutions. It’s easy to set up, and in this article we’ll walk through a simple Synergy example.

To start, find a project with a Synergy code file and open the project in Visual Studio 2017. Then right click on the project in Solution Explorer and select Add > New Item from the context menu (or press CTRL+SHIFT+A). Choose “Text File”, and change the name to .editorconfig, like so:

Now, open the .editorconfig file in the Visual Studio editor to add some settings. We’ll start by adding a root setting at the top of the file:

    root = true

The root setting is required and should precede all other settings in the file. We set root to true in this example to prevent Visual Studio from applying EditorConfig settings from other files. (Multiple .editorconfig files can apply to a project. The root=true setting prevents Visual Studio from looking any higher in the solution structure for other .editorconfig files.)

Next, we’ll specify which source files will be affected by subsequent settings in .editorconfig. For this example, we want settings to apply to every .dbl file in the project, so we’ll add a section heading under the root setting:

    [*.dbl]

A section heading consists of filename information enclosed in square brackets. As this example illustrates, wildcards can be used in section headings.

Now we’ll add editor behavior settings for .dbl files. We’ll start with indent style. For our example, we’ll specify spaces (rather than tabs) for indents by adding the following line after the section heading:

    Indent_style = space

Next, we’ll choose an indent size of 8 by adding this line:

    Indent_size = 8

We also want to trim all spaces preceding a newline, so we’ll add the following:

    Trim_trailing_whitespace = true

At this point, the .editorconfig file should look like this:

That wraps it up for this example. All we did was add a file to the project, give it the name .editorconfig, and add five lines. As long as this file is in the project, code typed in .dbl files will be formatted using these settings.

We can add this .editorconfig file to other projects and solutions, and we can add it to source control. To use this file for your team’s coding style, just add it to your team’s projects and source control repository. Then, if you need to make changes to the file, check it out, make the changes, and check it back in. Your team members will get the changes when they update.

The EditorConfig file we created here is very simple. Other options are available, such as end-of-line format (lf, crlf, cr) and character encoding (latin1, utf-8, and so forth). You can have more than one section (by adding additional section headings), which enables you to specify different settings for different source files. For more information, see the following:

• microsoft.com/en-us/visualstudio/ide/create-portable-custom-editor-options – Microsoft’s landing page for EditorConfig with samples and troubleshooting steps.
• org/#overview – The EditorConfig project landing page with samples and a list of supported editors, plug-ins, etc.
• com/editorconfig/editorconfig/wiki/EditorConfig-Properties – A full list of all supported properties and the values they take.

The EditorConfig project is open source, so if a feature you want is missing, you can contribute to the project at github.com/editorconfig.

We hope you’ll take advantage of EditorConfig to make it easier for you and your team to adopt a uniform coding style. If you have questions, contact Synergy/DE Developer Support; they will be happy to help.