Tabs or spaces: does it really matter anymore?

Tabs or spaces is the epical battle that any programmer has to assist at least once in his life. It’s a styling choice for a programmer, but it gets really serious when at least two programmers gets to collaborate in a project.

What’s the deal with that? Why is such stylistic choice so important? Technically they are different, being tabs more convenient for portability – but in the real world it doesn’t really matter.

As long as it is a solo programming it’s no big deal… until somebody sends that pull request where all spaces are replaced with tabs. And here people start to argue, asking to restore the previous style back.

The good news is, there’s a solution to this: automatic code formatters.

Tabs and spaces are only the tip of the iceberg, what about semi colons? In some languages they are mandatory, but in languages like Javascript they are kind-a optional. And what about other hundred rules/conventions?

But linters are already doing some code formatting, why can’t they be the only tool to do that?

Before answering such important question, we need to step back a little bit to trees, in order to build the foundations for the answer.

Trees

Code is just a sequence of words in a text file, so what’s this story about trees? Compilers, type checkers, linters and any tool that interact with code, create an intermediate data structure named AST (Abstract Syntax Tree) which abstracts any stylistic choices to focus only on content.

The AST is a tree representation of the code, used to navigate and reason about it in a performant and structured way. Having a structure to reason about the code enable tools to perform analysis on the code itself and even manipulate the content to provide a similar but more “efficient way” to reach the same goal.

If you want to dig more in the concept and understand how your code is effectively translated to the AST structure I can recommend the AST explorer tool to visually explore the AST structure of the code live.

Because of the convenience in reasoning with the AST data structure, many tools as linters, compilers, auto formatters use it to perform efficiently analysis on code.
If both linters and code formatters work with AST, what’s the difference between the two?

Why a code formatter and not a linter?

The technical reason a code formatting tool does a better job than a linter to do styling-based tasks is based on how the two tools make use of AST.

The way a linter works is a bit more complicated as it has to check many metrics (such styling or quality) of your code, therefore it has to collect all the conflicts in the AST while traversing it, then trying to solve it in a ordered way:

But what happens if there are overlapping conflicts – for instance a wrong variable and a mixed tab/space indentation in the same line? Well, in this case the first rule found in order is fixed and the rest of the conflicts are left unresolved. A new run may solve it, but many more errors may end up in the same area requiring many runs of the tool before solving them all.

The way a code formatter works with the AST is pretty simple compared:

It reads the code and simply print it in the configured way. The actual format/styling is completing ignored as the pure content is used to print the final output.

Eventually it can translate the AST tree in a slightly different one, but the translation is straightforward once the two AST definitions are documented:

Then tabs or spaces?

Well written code is consistent, and the best way to do so is having a tool that does the work for us. Configuring the linter and the automatic formatter tool that ensures that no matter what’s the style adopted it is always consistent with the company policy – or just yours.

But is there a tool to solve such problem? The answer is yes, there is: Prettier. Prettier is a tool that can be combined with your linter to automatically format your code with your styling conventions: configure how the code in the project should be formatted and that’s it. No more discussions, just profit.

Prettier is not the first code formatter tool out there, the idea is not original as Prettier itself was inspired by other code formatter tools – by refmt a ReasonML/OCaml formatter specifically -, but the original part of Prettier is its plugin structure that abstract the language itself for the formatting.

Compared to other language code formatting tools out there, Prettier leveraged the power of the AST in the formatting tool to provide a generic tool for any language via plugins.

It originally started for the Javascript language, then extended to the JSX syntax and all other JS-targeted languages (Typescript, Coffeescript, etc..) building up a generic structure to customise parsers and configurations in a modular way: this opened the path for a universal tool for code formatting.

If you want to try Prettier live before installing it, there’s a live playground.