EditorConfig; Share your editor settings
Table of Contents
Developers have strong opinions on all matters related to software
development. It is not uncommon to hear heated discussions on the
placement of braces or how to indent blocks of code.
Responsible teams quickly settle these disputes. The particular
choices hardly ever influence the code in a fundamental way. What is
far more important is that a code is written in a consistent style.
EditorConfig can help maintain a consistent style in a team, even when
developers choose to use their favourite tools.
1 EditorConfig
EditorConfig is
a file format for defining coding styles and a collection of text
editor plugins that enable editors to read the file format and adhere
to defined styles.
EditorConfig uses a INI format to specify the properties of groups of
files. An example .editorconfig file is given below.
root = true
[*]
charset = utf-8
end_of_line = lf
insert_final_newline = true
[*.js]
indent_style = space
indent_size = 4
[*.html]
indent_style = tab
[src/{main,test}/java/**.java]
indent_style = tab
tab_width = 4
1.1 Properties
EditorConfig allows the following properties to be specified.
indent_style |
“tab” or “space” |
indent_size |
a whole number |
tab_width |
a whole number |
end_of_line |
“lf”, “cr”, or “crlf” |
charset |
“latin1”, “utf-8”, “utf-8-bom”, “utf-16be” or “utf-16le” |
trim_trailing_whitespace |
“true” or “false” |
insert_final_newline |
“true” or “false” |
root |
special property that should be specified at the top of the file outside of any sections. Set to “true” to stop .editorconfig files search on current file. |
Let’s say you want to indent blocks with four spaces. This can be
specified with the following properties
indent_style = space indent_size = 4
Although it may seems to be a meager set of properties, it prevents a
lot of common inconsistencies when working with a team on the same
code base.
1.2 Glob patterns
You specify to which files the properties should apply by providing a
glob pattern. The glob patterns that EditorConf understands are
* |
Matches any string of characters except path seperators (/) |
** |
Matches any string of characters |
? |
Matches a single character |
[name] |
Matches a single character in name |
[!name] |
Matches a single character not in name |
{s1,s2,s3} |
Matches any of the string given |
For example, to select all java files in any package under the
standard maven directory structure, one could use the following
pattern
src/{main,test}/java/**.java
1.3 .editorconfig
The convention is to place the definitions in a .editorconfig
file. When tools and plugins try to determine what settings hold for a
certain file, they will look in the directory of the file and all the
parent directories until either the root of the file system is
reached, or a .editorconfig with the property root=true is
found.
All the .editorconfig files found are used. .editorconfig files
closer to the file under inspection take precedence.
1.4 Plugins
It is one thing to be able to define the code style, it is an other
thing to automatically enforce the definitions. Lucky there is a
growing list of plugins that do just that.
Chances are that you can find your favourite editor in the list of
currently available plugins.
- Appcode
- Atom
- Brackets
- Code::Blocks
- Emacs
- Geany
- Gedit
- GitHub
- IntelliJ
- Jedit
- Notepad++
- PhpStorm
- PyCharm
- RubyMine
- SublimeText
- Textmate
- Vim
- Visual Studio
- WebStorm
2 Conclusion
Being able that automatically enforces the style definitions over a
large range of editors is an indespensible tool for a modern day
software development team. EditorConfig provides excellent support for
that use case.