Consistent Style Across Editors
This content is more than 4 years old and the cloud moves fast so some information may be slightly out of date.
Consistent Style Across Editors
Sometimes, common themes occur if working on a project with multiple people and different development environments. One of the unexpected, time-consuming problems is related to editor configurations.
But it is pretty easy to unify things, if you know where to look…
Linebreaks
If you ever worked in a group of people who use different operating systems, you might have felt the pain of difficult line breaks.
Of course, you can yell at the others for not having the correct settings - but why not have GIT manage this for you?
Just add a file .gitattributes
in your project repository with these contents:
* text=auto eol=lf
And from now on, GIT will take care that everything is Unix-style (LF). If you never encountered the magic of GIT attributes, have a look at the gitattribute documentation. You can also limit this to specific file extensions by changing the wildcard at the start of the line.
Personally, I see this configuration only as a matter of last resort because I would like to avoid wrong editor settings in the first place. So let’s see how this can be solved.
Indentation and Whitespace
While there are community-standards for every language, not everyone is aware of them. So some might indent their code with Tab characters, others with 2 spaces and others with 4. The result is a wonderful mess, which gets especially apparent if you do Pull Requests.
For some of the basic settings, there is an editor agnostic approach called Editorconfig. It is just another hidden file in your GIT repositories (.editorconfig
) which specifies the most basic settings:
- end of line markers (again!)
- handling of whitespace at a line ending
- if a file needs a final newline to be acceptable
- indentation style and depth
- file encoding
My preferenced .editorconfig
looks like this:
root=true
[*]
end_of_line = lf
insert_final_newline = true
indent_style = space
indent_size = 4
charset = utf-8
trim_trailing_whitespace = true
But sadly, support for this is not automatically enabled everywhere.
Visual Studio Code
As Visual Studio Code is rapidly becoming the tool of choice for many in the industry, its extension ecosystem is booming. And with some small adjustments, it will even pick up on recommended extensions and … editorconfig files.
Put this in .vscode/settings.json
:
{
"recommendations": [
"editorconfig.editorconfig"
]
}
Now everyone who’s opening your project in VSCode the first time gets the editorconfig
extension recommended. As soon as they follow this suggestion, their code will honor the standards automatically.
If you are a pure VSCode shop, you can of course also add settings directly and have .vscode/settings.json
read like:
{
"editor.insertSpaces": true,
"editor.renderFinalNewline": true,
"editor.renderWhitespace":"all",
"editor.tabSize": 4,
"editor.trimAutoWhitespace": true,
"files.insertFinalNewline": true,
"files.trimTrailingWhitespace": true,
"recommendations": [
"editorconfig.editorconfig"
]
}
VIM 8
As a long-time user of VIM I often jump into the shell and do quick edits with it. Especially when I know that the adjustments are small, I hesitate to fire up Visual Studio Core.
Luckily, VIM has some built-in extension mechanics as well and can honor .editorconfig
with some plugin as well:
# Install the plugin
mkdir -p ~/.vim/pack/local/start
cd ~/.vim/pack/local/start
git clone https://github.com/editorconfig/editorconfig-vim.git
cat >> ~/.vimrc <<~CONFIG
set exrc
set secure
CONFIG
This will install the editorconfig extension in your profile and tell VI to use project-specific configurations.
Other editors
As far as I know, most major editors support editorconfig one way or another.
- JetBrains IDEs like PyCharm, IntelliJ, RubyMine and others: Extension from Marketplace
- Eclipse: Extension from Marketplace
- Sublime: Extension from packagecontrol.io
- for others, look directly at the EditorConfig project on GitHub
Give it a try and enjoy less screaming by your code linters (or colleagues). Have fun!