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.
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.
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.
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:
The way a code formatter works with the AST is pretty simple compared:
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.
If you want to try Prettier live before installing it, there’s a live playground.