Birth of Prettier(blog.vjeux.com) |
Birth of Prettier(blog.vjeux.com) |
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.
They fired me during the trial period after this PR.
Before this experience I was also "let's follow conventions even if they are bad", but now that I saw this argument applied so blindly against me, where I wasn't even allowed to use a common class to avoid duplicated code, I don't know, it just feels wrong.
3 weeks later and I'm still unsure if I was really wrong or just being gaslighted. I get conventions like "we split tests in create, get, etc. classes" or "the type of the incoming payload must be called `SomeEntityInput` and the output must be called `SomeEntityOutput`", but 70 comments? And you want me to duplicate code because that's what you did until now, "because conventions"?
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.
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.
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!
https://docs.github.com/en/repositories/working-with-files/u...
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.
(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:
important_numbers = {
"x": 3,
"y": 42, # Answer to the Ultimate Question!
"z": 2
}
important_numbers = {"x": 3, "y": 42, "z": 2} # Answer to the Ultimate Question!Apparently it's "an opnionated code formatter" - https://prettier.io
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.
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.
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.
Prettier allows configuring the indentation style (tabs/spaces) and indentation size, see https://prettier.io/docs/configuration#editorconfig.
I don't care about horizontal white space. That should just properly get indented and spaced into a consistent block format.
Did this not indent where I expected? Did it not change the formatting?
Do I use it as a crutch? Maybe. Would I be a better programmer if I didn't use it? I doubt it.
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.
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.
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.
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.