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…

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.

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

Similar Posts You Might Enjoy

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

Managing multiple stages with Terraform

Verwalten mehrerer environments in Terraform Zur Zeit ist dieser Artikel nur in Englisch verfügbar. - by Maurice Borgmeier

Managing multiple stages with Terraform

Managing multiple environments in Terraform Introduction I recently started learning Terraform. For those who haven’t encountered it: Terraform is in essence a framework to describe Infrastructure as code by Hashicorp. When I began doing that, I was struggling with the staging-concept of Terraform. I did my research and came upon numerous 1 articles and blogs that described ways to manage (multiple) environments or stages in Terraform2. Since I wasn’t really happy with the other solutions and there didn’t seem to be a canonical way to handle multiple environments, I decided to try and figure out my own solution. - by Maurice Borgmeier