Code formatters battle – who is nicer?

Why do I need one?

Every programmer has its own coding style. It is polite to honour the style of the file I am editing but when I am starting new file I will (some of) my style to the project. But sometimes you want to copy & paste code fragments from elsewhere. Or you or your colleague use code formatters or have rules for indentations – it is always nightmare to check git history and see a whole file changed just for one small typo correction (and lots of formatting changes).

Most of the teams have some common rules (do we use semicolons? etc.) but to follow them without help of tools might be inefficient. And if you already set up code formatter in the team – you can stop debating if your style is better than the other’s. It is really not that important to have the best possible coding style (as nothing like that will ever exist). And now you can focus more at your work 🙂

Contestants

We were comparing two most prominent JS code formatters: Prettier and standardJS. Both are pretty popular on Github, both supports different IDEs. Both allow to disable formatting for parts of your code when needed (e.g. you want declare a matrix variable). However when we compare npm downloads the trends favour Prettier.

StandardJS has strict rules and does not allow configuration. At least you don’t have to argue with colleagues. It is also more mature than Prettier that sometimes mess up with some edge cases. Anyway it is always best to review your commit changes.

Prettier on the other hand allows customisation to some degree (don’t worry you can have your single quotes). It does not support only JS but formats also CSS (either standalone or inline) or even GraphQL fragments. Its formatting rules are more complete as we will see later on.

Fight!

But let us look on the most important thing – formatting. We have (subjectively) compared the results for various code fragments and assigned points to both competitors. As we don’t want to go over all rounds (as your mileage may vary) we will jump to the results. In our internal competition Prettier wins by significant margin. But here are few examples of the formatting.

Spacing

Input

StandardJS

Prettier

Although standard complied about consistent spacing it was not fully successful to fix them. Prettier performed well in all situations that we have tried.

Long lines

Input

StandardJS – no change or warning.

Prettier

As we have noticed standard does not care about long lines at all. Prettier (little bit unfortunately) has only two modes for long lines – either fit all arguments in one line or  use only one per line. This works also vice-versa: Prettier will join arguments if they fits on one line – that’s cool.

This round had no clear winner – in some situations formatting left to the coder might be better here (as in standardJS case) but it leaves the possibility of too long lines which is not good. Consistency through code is better with Prettier.

Conclusion

We were convinced to Prettier. It works better with different file types, it seems to be faster but most importantly it makes nicer code. It will happen that you don’t agree with all its decisions but that is the trade-off that you can concentrate on writing code not formatting it.

How to apply it is another story – either you use format on save or even pre-commit hooks – it is up to you.