When you work in multiple teams, you quickly end up with different ideas on how the code you write should be formatted. “Tabs or spaces?” is something developer can argue for hours, have strong opinions about and are unwilling to change them. With only one setting in Visual Studio you are constantly changing it, or you end up reformatting the code. Both is annoying and not really a working solution.
Visual Studio 2017 has a new feature called EditorConfig, who addresses exactly this problem. Even better, this is not a Microsoft only approach, but an initiative by multiple vendors and projects (like JetBrains, GitHub, and many more.). You can find more details on EditorConfig.org, including examples and links to various projects using it.
How does it work?
You can create a .editorconfig in the root folder of your project and add it to your solution. Select the solution node in Visual Studio, right click on Add > New Item… and create a new text file with the name .editorconfig.
The rules specified there are then applied for all files in that level and the folders below. To get 2 spaces ad ident style for your C# and VB code, you add these lines to your .editorconfig file:
|
1 2 3 4 5 |
root = true [*.{cs,vb}] indent_style = space indent_size = 2 |
You can have multiple .editorconfig files in your project. If you set the root property to true, then the settings specified in folders above are ignored. If you want to reuse them and only overwrite specific property, you can set root to false:
|
1 2 3 4 |
root = false [*.{cs,vb}] indent_size = 4 |
This is especially helpful when you have legacy code that does not follow along your code guidelines and you don’t want to spent time changing everything.
Formatting code
Creating a .editorconfig file doesn’t change your code. Only when you explicitly tell Visual Studio to format your file (Edit > Advanced > Format Document or Ctrl+K, Ctrl+D in the default keymapping profile) will those settings be used.
If you set them to the values your project already uses, your code will not change at all. That may sound strange, but that is the whole purpose: Independently of the settings in your Visual Studio, the code is correctly formatted using the rules for that specific project. You don’t have to change anything in Visual Studio when you change to another project with different rules. If there is another .editorconfig file with the correct settings, you work as you always did and the formatting will be correct.
Support for writing .editorconfig files
Visual Studio has a plug-in that adds Syntax highlighting and code competition for .editorconfig files:
I like this little helper, especially for the menu item to add it to a solution. If you just want to format your code, then this plug-in is not necessary.
Conclusion
Try it when you work in multiple projects with different rules. It is quickly set-up and from then on you don’t have to do any manual reconfiguration. It just works and when the rules change, you have one place to update them.