Use Prettier to boost productivity and save time

by Jan Jadud

Writing code can be challenging on its own. You need to think about syntax, correctness, naming, placement, formatting etc...

There are many awesome tools that help developers in their daily lives with these and today I'd like to focus on one that addresses code formatting.

Code is being read more often
than it is being written

This is a mantra I keep close to my heart and despite the fact that it may not be obvious (it wasn't for me until I first heard it) I do believe that it subconsciously drives us to format our code as we write it.

After all, we want to quickly grasp it after we look at it again. Be it few minutes or months later.

Manual code formatting, however, has its problems.

Every new line of code presents an opportunity for it to be formatted.

Formatting code is not really a productive thing to do. The code is already there, formatting it doesn't bring any new functionality. Just think, how much of your time you spend writing code and how much of you spend formatting it? That time can be saved.

Unity is hard.

Staying true to the same style, formatting, naming etc. is hard even when programming solo. Every small change in context can subconsciously trigger a change. I won't even attempt to count how often I wrote class="some_name" in HTML and when proceeding to CSS file I somehow went for .some-name 🤷‍♂️. Now imagine trying to achieve unity in a team of 3 people. Now 30. It's hard because:

Everyone has a personal preference that can will come into question.

Raise hand everyone who, upon opening someone-else's code, starts tweaking it a bit by formatting just so it's easier on your eyes. Me: 🙋‍♂️. This personal preference is most visible during code reviews. Suddenly, there are diffs that actually don't bring any new functionality, just alter the formatting. There are comments that don't discuss the functionality, but rather that this 3 element-long array should list each one of them on new line, instead of it being a one-liner...

A PR that should have had at most 3 comments now boosts 30. Both author and reviewer are mentally exhausted from the cognitive load this puts on them.

It gets worse.

Author can will take it personally and if they decide to skip some of the commented changes, the reviewer becomes frustrated as they invested their time & effort and it's now being ignored.

Unfortunately, it gets even worse.

These differences in personal preference are easier to spot for a human eye, so they pop-up more easily for reviewer, distracting them from what actually may be important (hint: it's usually about what's not in the diff rather then what's in it). The more differences there are, the faster the reviewing fatigue comes and reviewer may even decide to not finish the review (at that time/at all).

Wouldn't it be awesome if we could somehow prevent all of this and instead focus on what's actually important?

Enter Prettier

Prettier is an opinionated code formatter that has very limited configuration options†. I was sceptical when a colleague brought it up for the first time at my previous job.

"Some fancy tool that formats my code? Not so sure about it... In the end, it's me who knows how the code looks best." I thought 🤔

I wasn't the only one feeling that way. We developers tend to be over-protective of our code. But then again, it's human to feel that way. And boy am I glad that we went for it in the end.

When implementing, the team went through some heated discussion† about how some of the configuration options should be set but that was it.

  • immediately, the comments regarding code formatting disappeared
  • code became unified and stayed so, even when new team members were onboarded
  • I (and I suppose others as well) stopped obsessing with formatting when writing code and spent more time actually programming

Now, after few years of using it, I honestly can't imagine my life without it. It's among the very first things I setup when starting a new project.

To start using Prettier, install it first:

yarn add prettier --dev --exact

To configure Prettier I use .prettierrc.js file as it's a standard JavaScript file that can be commented to explain choices and it's low enough in precedence order that it can be over-ruled by a custom .prettierrc file.

Note, that I list options even when they're set to their default values, because a change in major version of Prettier may (as it already did) change them.

// File: .prettierrc.js
module.exports = {
  // Custom	settings
  printWidth: 100,
  
  // Semicolons are not required in JS and rarely really needed
  // Personally I find them distracting
  semi: false,
  singleQuote: true, // Not so heavy on the eyes
  quoteProps: "consistent", // Leaning towards consistence
  
  // This is default value since 2.0.0; 
  // Easier refactoring, less noise in Diffs
  trailingComma: "es5", 

  // Defaults, just in case
  tabWidth: 2,
  useTabs: false,
  jsxSingleQuote: false,
  bracketSpacing: true,
  jsxBracketSameLine: false,
  arrowParens: "always", // This is default value since 2.0.0
  requirePragma: false,
  endOfLine: "lf", // This is default value since 2.0.0
}

There are multiple ways to actually apply Prettier's formatting to code and it's yet another thing I like about Prettier, because everyone's needs are covered.

Those whose don't obsess over formatting can setup an Editor integration and forget about it. Companies/code owners can force formatting with Pre-commit hook and those who want to have something different can run it manually using CLI.

I like to think about it in terms of Prettier providing unified start & goal line for everyone, but leaving enough freedom to choose your own coding methods in-between.

† This is a conscious (and ingenious) decision made by Prettier team. They correctly realised that providing options for many things would just move the conversations from code reviews to endless arguing about how each option should be set. Yes, in democraticaly-led teams this discussion will happen either way, but because of the limited number it will be much shorter and more focused on those "really" dividing-one options.