Throwing shade at Prettier

In the world of software, every project has its unique code dialect. Some projects indent with tabs; others favour spaces. Some projects organise code by feature into lengthy files; others keep their files as short as reasonably possible. Some projects eagerly introduce layers of abstraction and resemble a lasagna; others opt for a straightforward, spaghetti-like approach. There is no right or wrong, but maintaining a consistent dialect helps with comprehensibility. Thus, as an engineer, you try to make your code fit its surroundings. It comes with the territory.

One of the objectives of linters is helping us be more consistent. They perform static analysis and alert us if our code deviates from the agreed-upon dialect in certain specific ways. Static analysis particularly excels at finding formatting inconsistencies, specifically, and some linters can even reformat odd code for us.

Prettier stands apart from linters by concerning formatting only ‒ you are expected to use it alongside a linter ‒ and by taking formatting to its extreme. Prettier does not check whether your code is formatted according to the dialect. It assumes it is not, and reformats your code without exception.

For example, most linters enforce a maximal line length and will break up lines which exceed this limit. Prettier, as a consequence of its design, may merge two lines into one.

Some engineers love Prettier for this. They view formatting as a burden. If you use Prettier, you don't have to format at all. You can write complete messes if you want to, as Prettier disregards your formatting anyway.

That is a perfectly valid reason for using Prettier: wanting to delegate the chore of code formatting to an electronic butler. But the rise to fame of Prettier can be attributed to reasons which are not as valid.

Prettier "[stops] all the on-going debates over styles"

This quote is directly from the official website. Keep in mind: traditional linters impose either tabs or spaces, as well as whether braces should get their own designated line, et cetera. So that is not what they are hinting at here. They are referring to debates which reside in the wiggle room left by linters but taken away by Prettier. They are talking about disputes over whether two lines should be merged into one, and similar petty details.

Are debates over these things happening in your team? On-going debates, at that? It sounds to me like these debates are imaginary, conjured up to give Prettier a raison d'être. Are these truly taking place in your team? Run! This team will nitpick over trivialities until the end of time. Run while you still can!

Prettier "improves the quality of our codebase"

This is the most common argument I hear when I ask a team why they incorporate Prettier, although it does not come from Prettier directly.

Linters can protect the quality of your codebase. What Prettier offers beyond what a linter does, is hyper-predictable formatting. Formatting devoid of any human bias. Hyper-predictable formatting does not contribute to the quality of your codebase. Human bias in formatting ‒ within the boundaries defined by a linter ‒ confuses not a single reader of your code, as linters eliminate the opportunity for such confusion. Any residual human bias just doesn't matter.

If the mere idea of human bias in the formatting of your code is a source of sleepless nights, recognise it for what it is: a mini obsession. Let's not pretend that this has anything to do with quality.

Is Prettier bad?

In the author's opinion, Prettier does not bring anything substantial to the table if you are already using a component linter. On the cost side, it does introduce formatting quirks occasionally, and causes code to dance around more than necessary.

For those considering Prettier, go for it, but do it for the right reason: because you have something of a fetish for hyper-predictable formatting (I won't judge!), and/or you want to go easy on the tab key on your keyboard.