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.
DanielHB 6 hours ago [-]
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.
whstl 5 hours ago [-]
+1.
I'm a huge fan of custom linter rules.
Instead of going through PRs and nit-picking stuff, I just create new custom linter rules that catch those team-specific or project-specific things.
This has the positive effect of making things way more welcoming for junior devs and newcomers. Nothing replaces getting the first PR with almost no PR comments thanks to a linter.
I hate that a lot of people read the assertion that "PR reviews are a form of creating an internal coding culture" and become human linters, only nit picking PRs for the power trip. This is not only annoying but also makes people ignore the more important parts of the review.
I even made it a rule in every team I managed: if something is bothering you constantly in PRs and it can be replaced by a custom linter rule, let it go and write a linter rule for that later. I only met two people in my career who opposed this, and that was 100% because it made their nit-picking redundant.
harimau777 1 hours ago [-]
The difficulty that I've run into is that one person's nit is another person's essential change. My experience has led me believe that there are several different ways that developers approach reading code; resulting in developers placing different value on different style rules.
For example, when I am skimming code I primarily look at the code's "shape" and "flow". Where is there iteration? What code blocks are mutually exclusive? How does the code bail if there's an error? Etc. Therefore, things like indentation style and function decomposition are important to me because I need to be able to quickly see the overall layout of the code.
As far as I can tell, other developers read code using more of a "depth first" style where the overall layout isn't as important. As a result, they tend not to care much about things like indentation style or decomposition.
Hasnep 1 hours ago [-]
Which tools are you using that allow custom linter rules? I'd like to try this on some of my repos
whstl 28 minutes ago [-]
In ESLint I use eslint-plugin-local-rules and have my rules in a .js file (or folder) in the repo.
For golang I just use go/ast directly and make a small tool.
DanielHB 32 minutes ago [-]
eslint and biome allow custom lint rules and it is not that hard to write new ones yourself.
schwartzworld 3 hours ago [-]
I often say that “nit” comments on prs are bad. It’s either important enough to make a linter rule, or not important enough to mention.
fenomas 2 hours ago [-]
I wouldn't go that far - to me what's important is that nits must be non-blocking. I.e. the author is free to ignore them if they disagree, and a PR review with only nit comments should be an approval. If those things are true, it's fine to have gray area between what's linted and what's mentioned in PR review.
harimau777 1 hours ago [-]
100% agree! The pattern that I've found works well is:
Reviewing a PR with "Approval" status means that the comments are just suggestions.
Choosing "Comment" status means that the comments are optional but important enough that I want to make sure that you read them. If you come back and say "I read them but decided not to make any changes" then I'm happy to approve the PR.
Choosing "Request changes" means that the comments aren't just nits.
waisbrot 1 hours ago [-]
+1
For example, "nit: maybe call the function updateCreditCard instead of updateCard"
If you disagree and think your function name is better (or that the two are equally bad), then I'm happy to go along with what you've got. But maybe you didn't think of this name or maybe I've convinced you. Either it's a quick fix (and no re-review needed) or you just dismiss my comment.
CaptainOfCoit 3 hours ago [-]
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?
normie3000 5 hours ago [-]
> format-on-save
A dystopian feature!
whstl 5 hours ago [-]
I'll do one better: In the recent teams I worked, we even had "organize imports on save".
jjj123 1 hours ago [-]
I love format on save. I can type (or paste) ignoring whitespace, hit save, and everything pops right into place for me.
Also, stuff not auto formatting is usually immediate feedback that I didn’t match my parenthesis or have some other major syntax error.
speed_spread 3 hours ago [-]
Fight the power, setup format on checkout with your own rules.
hownowbrowncow 40 minutes ago [-]
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.
harimau777 2 hours ago [-]
I strongly dislike and disagree with 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.
cheema33 1 hours ago [-]
> I strongly dislike and disagree with Prettier.
Have you ever worked in a large team where everybody has their own idea on how code should be formatted? If not, then I can understand your position.
Do you get to review PRs where formatting changes make majority of the changes? Because some people don't use code formatters, others do but use different rules from each other. You may call this freedom, others may call it hell.
harimau777 1 hours ago [-]
I'm not opposed to establishing a coding style and using a linter to enforce it.
I'm opposed to doing that without getting buy in from the team. IMHO it's important to figure out whats important to the different developers on your team and finding a set of rules that works for them; as opposed to just adopting something that makes some people happy and tanks other people's productivity.
waisbrot 1 hours ago [-]
I agree that suddenly adding a formatter to existing code could be disruptive. But how does "buy in from the team" work over time? If you hire someone new and they don't like the format rules, do you stop using the formatter?
harimau777 1 hours ago [-]
I think it depends on the situation. If it's just not their preference then there's probably no need for a change. However, if it's going to prevent the new person from doing their job then a change is probably justified.
maerch 30 minutes ago [-]
People being prevented from doing their job because of code formatting? In my nearly 20 years of development, that statement was indeed true, but only before the age of formatters. Back then, endless hours were spent on recurring discussions and nitpicky stylistic reviews. The supposed gains were minimal, maybe saving a few seconds parsing a line faster. And if something is really hard to read, adding a prettier-ignore comment above the lines works wonders. The number of times I’ve actually needed it since? Just a handful.
Code style is a Pareto-optimal problem space: what one person finds readable may look like complete chaos to someone else. There’s no objective truth, and that’s why I believe that in a project involving multiple people, spending time on this is largely a waste of time.
cheema33 56 minutes ago [-]
> I'm not opposed to establishing a coding style and using a linter to enforce it.
Linters can enforce code formatting? Indentation and such.
> I'm opposed to doing that without getting buy in from the team.
That is generally a good principle for adopting any tool and not specific to Prettier or any other code formatter.
I have to admit I am somewhat confused about your objections to Prettier in particular.
CodingJeebus 2 hours ago [-]
The challenge is that it’s easy to find fundamental disagreements on a team on how a codebase should be styled, especially when the language itself doesn’t provide much guidance on styling convention. When that happens, it’s easy for a debate around styling to go on without ever finding consensus.
I’m way more open to adopting coding style that’s not my personal taste as long as it’s consistent and tools like prettier really help with that.
harimau777 1 hours ago [-]
I can see how that would be a challenge. I think the key may be to focus on identifying which things are just a given developer's preference and which are essential to their productivity. Like you said, I'm more than happy to adopt a style that isn't my personal taste. The problem comes when the style prevents me from doing my job.
mpalmer 58 minutes ago [-]
> Just because something isn't important to you doesn't mean that it's not essential to someone else.
The problem with this as an argument is that its opposite is equally valid.
Team dynamics are definitionally not about the concerns of the individual. The team is not helped by one person's insistence on handcrafted whitespace.
jotaen 47 minutes ago [-]
> In particular, by not allowing the user to change indentation style Prettier makes JavaScript much more difficult to read.
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
dleeftink 5 hours ago [-]
Wouldn't that result in having to reorient yourself between the formatted/non-formatted files when comparing commits and messy code that is being worked on?
Mind, I do value auto-formatting but wonder about the navigational costs when used this way.
jacknews 3 hours ago [-]
maybe code should be stored with no formatting, only the required whitespace, and the editors/viewers are responsible for applying formatting. Then formatting will never cause confusion in diffs.
NoSalt 20 minutes ago [-]
The formatting "standard" simply boils down to who the biggest fish in the small pond happens to be at the current location in time and space.
ieie3366 1 hours ago [-]
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.
> 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.
That Github issue doesn't really stress how serious he problem is. They make it sound like unnecessary parentheses get removed when they should be kept for clarify. What actually happens is that necessary parentheses get removed, altering the meaning of the expression. The example I encountered myself was this or similar to it (can't remember exactly):
(a || b) && c --> a || b && c
which then gets interpreted as
a || (b && c)
lifestyleguru 2 hours ago [-]
A lot of tools are fucking up the parentheses and apostrophes. Unnecessarily adding, removing, matching, or closing them. In terms of parentheses and apostrophes I know what I'm doing, stop "helping".
maratc 2 hours ago [-]
It's just not a big issue today if you know what you're doing or not, as everyone now seems to care about "consistency" only.
My personal pet peeve is python's formatter named "black" (mentioned in TLA) that converts this:
important_numbers = {
"x": 3,
"y": 42, # Answer to the Ultimate Question!
"z": 2
}
into this:
important_numbers = {"x": 3, "y": 42, "z": 2} # Answer to the Ultimate Question!
ezarowny 25 minutes ago [-]
I imagine if you add a comma to the end of the `"z": 2` line, Black will not try and push the dict onto a single line.
Rendered at 14:10:35 GMT+0000 (Coordinated Universal Time) with Vercel.
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.
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.
I'm a huge fan of custom linter rules.
Instead of going through PRs and nit-picking stuff, I just create new custom linter rules that catch those team-specific or project-specific things.
This has the positive effect of making things way more welcoming for junior devs and newcomers. Nothing replaces getting the first PR with almost no PR comments thanks to a linter.
I hate that a lot of people read the assertion that "PR reviews are a form of creating an internal coding culture" and become human linters, only nit picking PRs for the power trip. This is not only annoying but also makes people ignore the more important parts of the review.
I even made it a rule in every team I managed: if something is bothering you constantly in PRs and it can be replaced by a custom linter rule, let it go and write a linter rule for that later. I only met two people in my career who opposed this, and that was 100% because it made their nit-picking redundant.
For example, when I am skimming code I primarily look at the code's "shape" and "flow". Where is there iteration? What code blocks are mutually exclusive? How does the code bail if there's an error? Etc. Therefore, things like indentation style and function decomposition are important to me because I need to be able to quickly see the overall layout of the code.
As far as I can tell, other developers read code using more of a "depth first" style where the overall layout isn't as important. As a result, they tend not to care much about things like indentation style or decomposition.
For golang I just use go/ast directly and make a small tool.
Reviewing a PR with "Approval" status means that the comments are just suggestions.
Choosing "Comment" status means that the comments are optional but important enough that I want to make sure that you read them. If you come back and say "I read them but decided not to make any changes" then I'm happy to approve the PR.
Choosing "Request changes" means that the comments aren't just nits.
For example, "nit: maybe call the function updateCreditCard instead of updateCard"
If you disagree and think your function name is better (or that the two are equally bad), then I'm happy to go along with what you've got. But maybe you didn't think of this name or maybe I've convinced you. Either it's a quick fix (and no re-review needed) or you just dismiss my comment.
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?
A dystopian feature!
Also, stuff not auto formatting is usually immediate feedback that I didn’t match my parenthesis or have some other major syntax error.
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.
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.
Have you ever worked in a large team where everybody has their own idea on how code should be formatted? If not, then I can understand your position.
Do you get to review PRs where formatting changes make majority of the changes? Because some people don't use code formatters, others do but use different rules from each other. You may call this freedom, others may call it hell.
I'm opposed to doing that without getting buy in from the team. IMHO it's important to figure out whats important to the different developers on your team and finding a set of rules that works for them; as opposed to just adopting something that makes some people happy and tanks other people's productivity.
Code style is a Pareto-optimal problem space: what one person finds readable may look like complete chaos to someone else. There’s no objective truth, and that’s why I believe that in a project involving multiple people, spending time on this is largely a waste of time.
Linters can enforce code formatting? Indentation and such.
> I'm opposed to doing that without getting buy in from the team.
That is generally a good principle for adopting any tool and not specific to Prettier or any other code formatter.
I have to admit I am somewhat confused about your objections to Prettier in particular.
I’m way more open to adopting coding style that’s not my personal taste as long as it’s consistent and tools like prettier really help with that.
The problem with this as an argument is that its opposite is equally valid.
Team dynamics are definitionally not about the concerns of the individual. The team is not helped by one person's insistence on handcrafted whitespace.
Prettier allows configuring the indentation style (tabs/spaces) and indentation size, see https://prettier.io/docs/configuration#editorconfig.
Apparently it's "an opnionated code formatter" - https://prettier.io
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!
(a || b) && c --> a || b && c
which then gets interpreted as
a || (b && c)
My personal pet peeve is python's formatter named "black" (mentioned in TLA) that converts this:
into this: