Code formatters battle – who is nicer?

Code formatters battle – who is nicer?

Posted by Stanislav Miklik | September 8, 2017 | javascript

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 🙂


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.

Screenshot 2017-09-08 14.10.12

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.


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.





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


StandardJS – no change or warning.


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.


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.

Add a comment

*Please complete all fields correctly

Related Blogs

Posted by miklik | 24 February 2017
Recently we were invited to help others to resolve compatibility issues between IOS and Android. They have started with React Native but have developed their application only for Android. And…
Posted by miklik | 19 December 2016
What do you want for christmas? We wanted a color picker for React Native but we could not find any. Therefore we made one for you. You can find it…
Posted by miklik | 30 October 2016
This year we have decided to make our first open source project. It is context menu component for React Native. However right now we don't want to talk about the…