loading...

Why Prettier

tibfib profile image Will Honey ・3 min read

At my previous job, I was the lead frontend developer at a small startup. I was also the only frontend developer. As such, I could do basically whatever I wanted. I heard about Prettier through twitter and decided to try it. I immediately loved it and added it as a pre-commit hook. I stopped caring about formatting my code. I just typed it out, pressed save, and like magic, prettier would make it look good enough.

Eventually I left that job to try out a bigger team at a bigger company. I was hired on as a senior frontend developer–with two others already on the team. I immediately suggested adopting prettier to my coworkers and was met with a lot of resistance. The complaints:

  1. I just don't like the way it looks.
  2. It uses way too much vertical space.

I disagreed with both of those complaints, but wanting to be a good new coworker, I eventually lessened the pressure; only bringing it up in side comments ("Yeah, I really like how typescript hero takes care of the imports and sorting for me. That's one thing I really like about Prettier too–how it automates a lot of stuff I don't need to do manually").

As I became more familiar with the codebase I started creating more and more pull requests for the tasks in our JIRA board (don't get me started there). I was a little nervous to see how my code would be received–after all I had mostly worked as a solo frontend dev for the majority of my career. I was crestfallen to see that my first few PRs were filled with comments and "needs work" stamps. It made me feel really bad. Like, am I not a good programmer?

95% of the comments were about formatting issues. "We put an extra line here." "We prefer to put a comma here." "We do it this way." My first few pull requests, when I needed the most validation, were ripped to shreds because we didn't use Prettier.

As Dan Abramov tweeted,

We need something to obsess about. We learn mechanical rules and to feel good about following them. Much easier than fixing bugs! We impose them on new team members — here’s how WE do things, you forgot a SPACE here and SEMICOLON.

This is madness. Break the cycle. Use Prettier.

Gradually I learned their coding styles and the style comments lessened. Now, five months after I started, the team has agreed to use Prettier. It just kind of... happened. I brought it up in earnest this week and I think my coworkers were more open to it after I had been working with them for a while. The frontend team lead decided to do some investigation and in the end was willing to give it a try.

We spent much of the day arguing about the Prettier settings (initially they wanted 180 character columns!) but eventually came to a consensus. We all have Prettier in our respective editors with our .prettierrc in the repo. I have a good feeling this'll be one of the last times we argue about code style.

Discussion

pic
Editor guide
Collapse
nickytonline profile image
Nick Taylor (he/him)

I definitely agree that arguing over coding style is such a waste of energy in PRs. Focus on real issues.

If you ever feel like contributing to the dev.to codebase, you'll be happy to know there's prettier and pre-commit hooks care of husky. It was one of my first PRs to the dev.to repo.

github.com/thepracticaldev/dev.to/... (note the PR link is incorrect in the commit because the codebase was originally private)

Happy Coding! (Yes I just listened to your Product Hunt interview @ben 😉)

Collapse
glennmen profile image
Glenn Carremans

I think people are skipping the pre-commit hook, check my comment in my PR and in my last post:

Added GitHub PR liquid tag support #1784

Glennmen avatar
Glennmen commented on Feb 11, 2019

What type of PR is this? (check all applicable)

  • [ ] Refactor
  • [x] Feature
  • [ ] Bug Fix
  • [ ] Documentation Update

Description

Add support for Github pull request via liquid tags in markdown. {% github https://github.com/thepracticaldev/dev.to/pull/1633 %}

My first time setting up a Ruby environment and actually developing in Ruby, so let me know if I should have done things differently.

I also fixed a couple of pre-commit errors, strange that the thrown errors where from parts that I didn't edit. So I assume that a lot of people skip the pre-commit check with --no-verify. Anyways the only error I couldn't fix was this section because it would parse the html instead of showing it in the codeblock: github.com/thepracticaldev/dev.to/...

Related Tickets & Documents

Closes #1760

Mobile & Desktop Screenshots/Recordings (if there are UI changes)

Desktop

Added to documentation?

  • [x] help tab in the markdown editor
  • [ ] docs.dev.to
  • [ ] readme
  • [ ] no documentation needed

[optional] What gif best describes this PR or how it makes you feel?

THUMBS UP

Collapse
ryansmith profile image
Ryan Smith

I am all for consistency. I don't care much about tabs or spaces, semicolons or no semicolons, 80 or 120 character limit. All that I ask is to pick one, stick to it, and fix code that is copied and pasted in. Even better if all of that can be automated.

Collapse
tibfib profile image
Will Honey Author

I think the automation is really key for me. I'll do whatever style you want as long as I don't actually have to do it. Haha.

Collapse
rikschennink profile image
Rik Schennink

I'm someone who obsesses over code style and I really don't want to. Prettier worked quite well to prevent me from wasting precious time formatting code.

Unfortunately, Prettier removes parentheses where it sees fit. I had to stop using it because my brain really needs them to stay put.

parenthesis removed

Any way to solve this?

Collapse
tibfib profile image
Will Honey Author

Honestly, I'd just use the prettier-ignore comment to keep the parentheses. Hopefully you don't feel like you have to do this multiple times in a single file. But once in a while I think it's okay.

See prettier.io/docs/en/ignore.html

// prettier-ignore
var foo = (1 /10) + 100;

You could consider opening an issue on the prettier repo to see if others share your opinion.

Collapse
jf1 profile image
Collapse
rikschennink profile image
Rik Schennink

Thanks, will surely give it another try!

Collapse
jlouzado profile image
Joel Louzado

prettier is one of those things that feels like cheating initially, and like "why can't people just care more about styling manually", and then you use it on a project and it's just so blissful and you're like "why didn't I do this sooner" 😅

Collapse
xngwng profile image
Xing Wang

it also makes the git commit/diffs also much more clearer.

Collapse
btsuhako profile image
Blake

Great article! Could you post a gist of your .prettierrc?

Collapse
tibfib profile image
Will Honey Author

This is the one I use in all of my personal projects.

{
    "semi": true,
    "singleQuote": true,
    "trailingComma": "es5",
    "printWidth": 100,
    "arrowParens": "always",
    "tabWidth": 4,
    "endOfLine": "lf"
}

Our new company one differs by having printWidth be 140 (that's as low as I could convince them) and "arrowParens" is "avoid". I personally like having the arrowParens but I had to let that one go.

Collapse
qm3ster profile image
Mihail Malo

Want the "arrowParens"? Make them use TypeScript, the type annotation of the single arg will add the parens most of the time :)

How come "trailingComma": "es5" and not "all"? Git diffs, my dude :v

I will not mention the semicolon :v
OH NO, I ACCIDENTALLY MENTIONED THE SEMICOLON :v

Collapse
joelnet profile image
JavaScript Joel

I am currently using eslint + prettier + husky in my projects. It's a pretty strong combo. I really like it.