Tabs versus spaces; two spaces versus four; Windows versus Unix line endings: code editor settings differ per device and developer, which can be a hassle working in a team. There is an easy way to share base settings, and it's called EditorConfig.
In this article, I will show you the basics of EditorConfig. The official documentation is already quite comprehensive, and I encourage you to check out the official EditorConfig Specification.
An example
The EditorConfig configuration file .editorconfig is one of the first files I put into any repository.
Let's take a look at a setup for Python and Django projects:
# https://editorconfig.org
# https://editorconfig-specification.readthedocs.io/
root = true
[*]
charset = utf-8
end_of_line = lf
trim_trailing_whitespace = true
insert_final_newline = true
indent_style = space
indent_size = 4
[*.html]
indent_size = 2
[*.json]
indent_size = 2
insert_final_newline = ignore
[*.{yml,yaml}]
indent_size = 2
[Makefile]
indent_style = tab
So what is happening here?
Root
root = true
This little line tells EditorConfig to stop looking for other EditorConfig configuration files and use this one for all files in the codebase.
The area above the first set of rules (marked by [*]) is called the preamble, and you must put the root rule in this area.
Note: The preamble also contains links to official EditorConfig websites; those are there for convenience only.
Base rules
[*]
charset = utf-8
end_of_line = lf
trim_trailing_whitespace = true
insert_final_newline = true
indent_style = space
indent_size = 4
The base rules, shown under [*], are the first rules in the configuration file. We work with UTF-8 encoded files that use Unix line endings, and we trim trailing whitespace from lines but force a file to end with a newline.
The indent style is four spaces, which aligns with Python's PEP 8 – Style Guide for Python Code.
Note: You are perfectly free to use tabs instead of spaces. Heck, that would be a readability boost for some. Just change it, and don't start a flame war.
Specific filetype rules
[*.html]
indent_size = 2
[*.json]
indent_size = 2
insert_final_newline = ignore
[*.{yml,yaml}]
indent_size = 2
[Makefile]
indent_style = tab
Now we're getting to the exceptions to the base rules. Some were born out of preference, others out of existing code styles.
Set 1 changes the indent size for HTML files to two spaces. The main reason for this is space: there is a lot of nesting in HTML files. Decreasing the indentation size reduces the need for horizontal scrolling.
Set 2 sets JSON indent size to 2 and removes the need for adding a final newline. This ruleset is specific to one of my projects, defined because it was the easiest way to work with JSON files used only for test data.
Set 3 uses a simple pattern to apply the same settings to YAML files with either the .yml or .yaml extension. I'm sure there is a flame war raging Somewhere On The Internet™️ about which extension is best, but here we target both versions and be done with it.
Set 4, the final one, is perhaps the most crucial of them all. Makefiles don't offer you a choice of indentation: it's tab or bust. Our default indentation uses spaces, so our EditorConfig would break Makefiles if not for this custom ruleset.
Note: You could choose to merge some of the rulesets above. I decided against joining them because it's easier to manage on a per-filetype basis, but that is just preference.
Rules are only guidelines
It is important to note that EditorConfig does not enforce its settings. A developer can choose to bypass the settings defined in the configuration and use whatever they fancy.
EditorConfig support
Support for EditorConfig is advanced to a point where modern editors have it baked in.
Wrap-up
Use EditorConfig to automatically share default code editor settings throughout a team, with the creation of just one file!