Consistent cross-IDE formatting for teams/projects
Tags: productivity, style, codequality
Published: 2019-11-29 11:33:35

**TL;DR**: [EditorConfig](https://editorconfig.org/) allows code formatting settings to be checked in to source control and is supported by [most](https://editorconfig.org/#download) editors.

## Style Stew
### Background
Our current team consists of developers from various backgrounds, which is code for saying that everyone likes to do things their way.

Nothing wrong with free will but, without reviving the whole spaces vs tabs debate, it means that every developer has their preference and editor/IDE of choice.

### Problem
Being big fans of not losing days worth of work when your laptop crashes, we keep all our code in source control (yay us), but when changes have to be merged in source control, the free-for-all philosophy comes back to bite you right in the proverbial semi-colon.

See, the thing is, as clever as the merging strategies are, spaces, tabs, LF's and CRLF's are all very distinct thus the onus of having to resolve the conflicts falls on the person reviewing the pull request.

### Chaos
This leads to some interesting keyboard throwing and mouse bashing sessions, which are all entertaining to watch, but not really productive. Call me a drama llama but having to resolve conflicts day in and day out is really no fun.

## Fiddle with formatting
So having thrown all my toys out of the cot, we decided to do something about it.

### Initial attempts
Our first attempt at preventing a complete merge meltdown was to just ask everyone to set their editors to use 4 space tab indentation. This actually showed some promise as for the next while we could assimilate code in a way that would make even [Donna Haraway](https://en.wikipedia.org/wiki/Donna_Haraway) proud.

Then someone decided to switch from Visual Studio to Jetbrains Rider and immediately we were back to red. Pull request builds kept failing the one after the other. This time the culprit was line endings.

Having cross-platform Jetbrains Rider at his side, our dear colleague was happily coding on his new *nix box, leaving the code with LF's instead of the more preferred Windows style CRLF.

We then configured our GIT repo to save only CRLF's, which solved our merge issues, but left our Rider friend hanging out to dry each time he pulled a change.

Something had to be done and soon. Surely there has to be a way to have your formatting and eat it too (I know, that one went too far, sue me).

## EditorConfig enlightenment
### Solution
One sunny June morning I was browsing [HackerNews](https://news.ycombinator.com/) and in one of the articles, my eye caught something, something called EditorConfig.

In true dev fashion I skimmed the [documentation](https://editorconfig-specification.readthedocs.io/en/latest/) and realized that this could make life so much easier. You could define settings, have it checked in to source control, and then have your editor/IDE apply those settings on a per project basis regardless of personal preference.

You simple have to create `.editorconfig` file in your project directory and declare the required settings.

We could specify line endings
`end_of_line = crlf`

Get rid of trailing whitespaces
`trim_trailing_whitespace = true`

Set indentation
`indent_style = tab`
`indent_size = 4`

_Read the full documentation [here](https://editorconfig.org/)_

#### Personal
For me personally this meant that I could use whatever editor I wanted, on which ever machine I wanted, and the code dictates the required settings for basic styles.

#### Team
In our team this, in conjunction with ESLint/TSLint lead to us being able to even outsource work as we no longer had to spend hours explaining our code formatting requirements and merge issues.

#### Conclusion
If you are serious about being consistent when it comes to code quality and also want to make your life as a developer easier, I would seriously encourage you to give EditorConfig a try as a small Quality-of-life improvement.

Happy coding