Scott Addie

Last Updated: 1/18/2016

The Problem

Imagine being assigned to a project team on which discord is abound in regards to the editor or IDE to be used for the development of a new application. Most of the team members favor one product strongly over the alternatives; and, that favoritism may be directly attributed to the developers’ skillsets and/or experience levels. To compound the problem, not all developers prefer the same operating system. As a .NET developer on Windows, the clear winner is the Visual Studio proper IDE for its outpouring of battle-tested tooling. But what about a .NET developer on Mac OS X or Linux? Visual Studio proper shies away from those platforms, so Visual Studio Code is the champion of Microsoft’s offerings. The Node.js developers prefer something lighter weight, such as Visual Studio Code, Sublime Text, or Brackets; or, maybe a JavaScript IDE such as WebStorm is preferable for the extra assistance it provides. What a mess!

In the enterprise, this dilemma is less common thanks to the tight controls imposed by the internal application architecture practice. The open source world, on the other hand, is riddled with this obstruction. All of a sudden, the liberation of choice isn’t such a perk.

As a frequent open-source contributor to various projects on GitHub, I see an increasing number of project maintainers attempting to solve the problem. Religious debates unfold amongst contributors over seemingly menial details such as line termination characters and spacing preferences. Is it a tab or a space? If it’s a space, how many? What’s the preferred character set? These decisions should be made early on to ease the pain of merging pull requests submitted by contributors.

For the remainder of this write-up, the focus will shift to Visual Studio 2015. I find myself toggling between it and Visual Studio Code on a daily basis and have found a simple way to solve some of the problems described above: EditorConfig. Unfortunately, these two Microsoft tools lack native integration with EditorConfig, so additional configuration is required.

Visual Studio 2015: Installation & Configuration of EditorConfig

Below are the four steps involved to begin using EditorConfig in a Visual Studio 2015 environment. The end result is that Windows-style (Carriage Return + Line Feed) newlines are enforced, and a blank line is inserted at the end of any file upon saving.

Step 1: Install the EditorConfig extension.

Step 2: Add an empty .editorconfig file to the project root or solution folder. When present in the solution folder, the settings are applied to each project in the solution. Here are two options for creating the file:

1. Use the Add New File extension
2. Open a command shell, and execute the following command at the project root folder:

   null > .editorconfig

Soon, an item template will be available, per this pull request.

Step 3: Define the desired settings in .editorconfig, save the file, and close it:

Step 4: If the .editorconfig file is in the solution folder, then open any file in any project (yes, it could even be the .editorconfig file), modify it, save it, and notice the blank line which now appears at the end of the file. If the blank line was already present, no change takes place.

Restricting Settings to Certain File Types

What if the changes above shouldn’t be applied to every file type in the solution or project? By modifying the file path glob on line 5 of the gist above, we can easily target just C# and JavaScript files like so:

More extensive documentation of the file path globbing patterns is found here.

Validating the end_of_line Setting

Now assume that we’ve decided to adopt Unix-style newlines instead of the Windows-style CRLF. A staggering number of developers on the team are now running Visual Studio Code on Linux exclusively, so the LF newline style makes most sense. The original gist provided above would look as follows:

After saving the .editorconfig file, it’s a good idea to close and reopen the solution again to ensure that this updated newline setting is applied. Now save any file in the solution. The resulting newline change isn’t easily noticeable in Visual Studio 2015 until the following dialog begins to appear:

If, by chance, something like this goes undetected in the IDE, GitHub has a safety net in place which will warn about it when displaying code diffs:

Final Thoughts

EditorConfig is an indispensable tool which I regret not discovering sooner. At the time of writing, it lacks native integration in Microsoft’s tools, hence the need for plugins/extensions. The subset of supported properties in Visual Studio’s plugin can be found here. Check the official plugins page to determine whether your editor/IDE of choice has native support or requires a plugin.