Consistent Style Across Editors

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…


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:


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": [

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.tabSize": 4,
  "editor.trimAutoWhitespace": true,
  "files.insertFinalNewline": true,
  "files.trimTrailingWhitespace": true,
  "recommendations": [


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

cat >> ~/.vimrc <<~CONFIG
set exrc
set secure

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.

Give it a try and enjoy less screaming by your code linters (or colleagues). Have fun!

Similar Posts You Might Enjoy

VSCode Repository-Level Task Definitions

Do you run the same CLI commands again and again while using VSCode? Even if you already put them into code, you find yourself typing things like rake build all the time? I just learned of VSCode’s integrated Task management the other day, and this knowledge could help you work more productively. So let’s dive deep… - by Thomas Heinen

The declarative vs imperative Infrastructure as Code discussion is flawed

“Infrastructure definition has to be declarative”. Let’s see where this presumption gets us. My guess why some ops guys prefer pure terraform or CloudFormation is that these languages seem to be easier to understand. There is precisely one way of creating a specific resource in the language. If you use a programming language, there are many ways to solve one specific problem. The problem which could occur later in the project is that both declarative languages have boundaries in what they can do, with a programming language you do not have these boundaries. - by Gernot Glawe

Building Lambda with terraform

Note: This is an updated version of this blog. Building Lambda Functions with Terraform Introduction Many of us use Terraform to manage our infrastructure as code. As AWS users, Lambda functions tend to be an important part of our infrastructure and its automation. Deploying - and especially building - Lambda functions with Terraform unfortunately isn’t as straightforward as I’d like. (To be fair: it’s very much debatable whether you should use Terraform for this purpose, but I’d like to do that - and if I didn’t, you wouldn’t get to read this article, so let’s continue) - by Maurice Borgmeier , Alexey Vidanov