When I first tried out Prettier back in the 2010s, I was immediately hooked on the idea of using an opinionated formatter. We had constant arguments about formatting, and our many JS codebases were a complete disaster as they had been worked on for many years by many people with nobody overseeing any of the formatting.
I was a zealot - I spent weeks going into every single one of our JS codebases, running Prettier on all of the files, setting up CI/CD rules to enforce it, and teaching everybody how to set up format-on-save in their editors. Some people whined about it ("I don't like the way it does curly braces! Waaah!") but I was persistent and unwavering.
All these years later, I'm elated that whenever I join a new company - engineering orgs almost always have all of this already set up, not just with JS/TS but almost every language out there. It makes getting up to speed on the actual content of the code so much faster.
If I join your engineering org and you aren't using enforced, automatic, opinionated formatting on every single line of code that gets written that's a huge smell.
One of my main pet peeves of working with other developers is people breaking from conventions because "it is not good". Yes even if a convention is bad you should still follow it, unstandardized codebase is the main root of all evil in large codebases.
I try to avoid setting up conventions that can't be statically enforced (or at least enforced through tests/assertions). So yes, auto-formatters are a godsend because they statically enforce code-style.
It has become standard feature in most languages stacks these days because of Prettier and gofmt.
Sounds similar to my personal history of adopting StandardJS (https://github.com/standard/standard) as soon as it appeared, doing the same at the org I was at the time. Based on memory, seems StandardJS appeared before Prettier in the ecosystem?
It seems weird that StandardJS wasn't mentioned in this article, as surely the author must have known about it before starting Prettier.
Still to this day I just use StandardJS when starting a new project, not even sure what the difference against Prettier is, it's more or less the same as far as I can tell but maybe faster?
What I love about those tools is that you get the best of both worlds when you use them right. If you apply auto formatting in a pre commit hook, then you can format any way you want locally but whatever is in the repo is formatted uniformly. Fewer noise in diffs and total freedom
> One interesting side effect is that I changed the most number of lines of code company wide that year and got my name on the "blame" for most of the JavaScript files that existed at that time. So over the years I kept getting random people or scripts pinging me about code I had no idea about!
Not sure who needs to hear this, but in case anyone runs into this problem, you can create a list of commit hashes that `git blame` will ignore. Commit all of your formatting changes in one push and then put its hash in the ignore file.
From a practical standpoint, I disagree with the idea that coding style is just "bikeshedding". Coding style has a DRAMATIC impact on how readable code is and therefore how easy it is to understand. In my experience, fighting to keep code understandable is one of the most difficult and important parts of software engineering. In particular, by not allowing the user to change indentation style Prettier makes JavaScript much more difficult to read.
From a social standpoint, I think that by labeling things "bikeshedding", Prettier represents a toxic approach to team dynamics. Just because something isn't important to you doesn't mean that it's not essential to someone else.
IMHO, Prettier was a massive setback for the JavaScript community.
Looking back at it, just crazy how much effort and man-hours went to manually editing whitespace and arguing/nitpicking about it. This is something that should have been automated by the 90s.
Prettier and other format-on-save tools remain a huge quality of life improvement. I also think it found success because the defaults and choices outlined in the article were very wisely chosen: very readable in almost every context. The right tradeoffs were made both in printing logic and psychology with options/rollout.
One other subtle interaction that is hard to live without now: watching code shift with format-on-save is the fastest feedback on whether code will build/run. Don’t need to look at another console for a syntax error almost ever.
14 comments
[ 3.5 ms ] story [ 28.1 ms ] threadI was a zealot - I spent weeks going into every single one of our JS codebases, running Prettier on all of the files, setting up CI/CD rules to enforce it, and teaching everybody how to set up format-on-save in their editors. Some people whined about it ("I don't like the way it does curly braces! Waaah!") but I was persistent and unwavering.
All these years later, I'm elated that whenever I join a new company - engineering orgs almost always have all of this already set up, not just with JS/TS but almost every language out there. It makes getting up to speed on the actual content of the code so much faster.
If I join your engineering org and you aren't using enforced, automatic, opinionated formatting on every single line of code that gets written that's a huge smell.
I try to avoid setting up conventions that can't be statically enforced (or at least enforced through tests/assertions). So yes, auto-formatters are a godsend because they statically enforce code-style.
It has become standard feature in most languages stacks these days because of Prettier and gofmt.
A dystopian feature!
It seems weird that StandardJS wasn't mentioned in this article, as surely the author must have known about it before starting Prettier.
Still to this day I just use StandardJS when starting a new project, not even sure what the difference against Prettier is, it's more or less the same as far as I can tell but maybe faster?
Not sure who needs to hear this, but in case anyone runs into this problem, you can create a list of commit hashes that `git blame` will ignore. Commit all of your formatting changes in one push and then put its hash in the ignore file.
https://git-scm.com/docs/git-blame#Documentation/git-blame.t...
This feature was created as a direct response to automated formatters like Prettier!
From a practical standpoint, I disagree with the idea that coding style is just "bikeshedding". Coding style has a DRAMATIC impact on how readable code is and therefore how easy it is to understand. In my experience, fighting to keep code understandable is one of the most difficult and important parts of software engineering. In particular, by not allowing the user to change indentation style Prettier makes JavaScript much more difficult to read.
From a social standpoint, I think that by labeling things "bikeshedding", Prettier represents a toxic approach to team dynamics. Just because something isn't important to you doesn't mean that it's not essential to someone else.
IMHO, Prettier was a massive setback for the JavaScript community.
Apparently it's "an opnionated code formatter" - https://prettier.io
One other subtle interaction that is hard to live without now: watching code shift with format-on-save is the fastest feedback on whether code will build/run. Don’t need to look at another console for a syntax error almost ever.