Javascript

Why you need Prettier in your life if you work in a team

The title of this post is why you need it in a team. The reason it is so useful in a team is consistency and the lack of requiring an opinion.

Tech expert, journalist, social media commentator, amateur cartoonist and robotics fan.

Published · Mar 14 2019

I’ll start with a question, which of the following lines of code is correctly formatted?
a) if ( this ) { foo('bar'); }
   const options = { width, height, title } = this.props;
b) if(this){
     foo("bar");
   }
   const options = { 
       width, 
       height, 
       title, 
   } = this.props;

Well, the answer should be “It doesn’t matter”. None of the variations in the code above will have any effect on the final result and caring what it looks like just slows us down and uses up cognitive load on problems that aren’t worth worrying about.

How about the following code?
if(this){
   foo("bar");
}
const options = { 
  width,height, title, 
  description, date, author, 
  image, ImageLarge
} = this.props;
It’s clearly a mess! The tabbing in inconsistent, and we’ve got some very long line lengths.

One way we could solve this is with ESLint and a stringent set of rules. But have you ever had to deal with an over zealous ESLint config? I have recently and it’s a bore. I’d create a component and then spend the next 10–15 minutes going through it adding spaces in the right places until it would finally accept my work. Meanwhile, I’d forgotten what I was trying to do in the first place. Total waste of time.

Prettier comes to our rescue! In its own words “Prettier is an opinionated code formatter. It enforces a consistent style by parsing your code and re-printing it with its own rules.”
. . .

Let’s take this a line key word at a time.
Opinionated
This means you don’t get to choose. No more team meetings about how we’re going to format code and the person that shouts the loudest doesn’t get theirway implemented, so it’s fairer. Should this have a line break? Spaces inside parenthesis? Who cares — we’re doing it the way Prettier wants!
Consistent
Consistency is a must when you have multiple developers working on the same projects. The code looks how you expect it to look regardless of who created it. You can’t moan that someone used a single tab when it should have been four spaces, or that they’ve put white space where there should be none — it’s the same every time, and it’s no one’s fault — Prettier did it!
Reprinting
This thing is automatic. You don’t have to tell it to run, you don’t have to go bak through it until it’s happy. It ‘just works’ and works the same way every time.


  
Prettier with ESLint
Why do we need Prettier when we’ve got eslint? Use Prettier for formatting, and linting for what it was meant for — functionality. Use eslint to ensure you haven’t left variables in that aren’t being used, and that you haven’t littered your production code with console logs.

Even with ESLint, I’d opt of using a set of recommended values. Again, if you configure, your opining. If you opine, you have to justify, this leads to discussions, meetings, cognitive capacity being taken away from coding output, wasted on superfluities.

Here’s an example of how I’ve set up ESLint with Prettier in my React projects where I’m using the latest JavaScript (transpiled with Babel).
Using within code editors
Just about every code editor has support for Prettier available. You can make it run on save. This is how it looks:

 From https://jlongster.com/prettier-1.0 

 It’s pretty handy, but can be a little annoying and distracting. I tend to leave my code written however the hell I’ve written it and let Prettier worry about it for me later. I still write single quotes and put spaces where I want them, and have long running lines. When I commit my work, it’s taken care of, and no one has to ever see my badly formatted code.
Running as a pre-commit hook
So, how do we have it run when we commit? With a git hook. You can manage and write these yourself or use a package such as husky and another package called lint-staged. Together, these allow me to tea-up all the files that I have edited since my last commit, run them through Prettier and ESLint before they get committed.
Configuration
You can configure Prettier, but arguably you shouldn’t. In fact, when it first came out, you couldn’t configure it at all. It’s opinionated and that’s the point. I’ll let you in to a secret, it’s not that it will format the code the way that will make everyone happy, in fact, it’ll probably format it in a way that makes everyone equally upset. 

And that’s kind of a win. You can tell it to favour single quotes (it aims to use the quote method with the fewest escapes possible and defaults to double-quotes), you can change it’s line-length, bracket spacing and the like. But I really recommend you don’t. Once you start configuring it, it’s your opinion, not Prettier’s, and you have to justify it. If it’s just “how Prettier does it” you can offload the blame, stop having discussions and get on with your day.

Conclusion
The title of this post is why you need it in a team. The reason it is so useful in a team is consistency and the lack of requiring an opinion. If Prettier tells you how it is, no one person in the team dictates and no unnecessary meetings around code-formatting need to take place. If you haven’t tried it already, give it a go — you’ll never look back!