Last Updated: 1/18/2016
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:
- Use the Add New File extension
- 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
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:
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.