_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
URI Visit Hacker News on the Web
COMMENT PAGE FOR:
URI Birth of Prettier
NoSalt wrote 2 hours 9 min 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.
hownowbrowncow wrote 2 hours 29 min 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.
ieie3366 wrote 3 hours 6 min 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.
eps wrote 3 hours 18 min ago:
Never heard of it.
Apparently it's "an opnionated code formatter" -
URI [1]: https://prettier.io
Aldipower wrote 3 hours 32 min ago:
Someone remembers 'perltidy'? :-) Was this the birth of code
formatters?
harimau777 wrote 3 hours 33 min 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.
jotaen wrote 2 hours 36 min ago:
> In particular, by not allowing the user to change indentation style
Prettier makes JavaScript much more difficult to read.
Prettier allows configuring the indentation style (tabs/spaces) and
indentation size, see [1] .
URI [1]: https://prettier.io/docs/configuration#editorconfig
mpalmer wrote 2 hours 47 min 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.
cheema33 wrote 3 hours 18 min 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 wrote 3 hours 15 min 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.
cheema33 wrote 2 hours 45 min 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.
waisbrot wrote 3 hours 10 min 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 wrote 3 hours 5 min 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 wrote 2 hours 19 min 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.
CodingJeebus wrote 3 hours 28 min 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 wrote 3 hours 12 min 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.
rendall wrote 4 hours 2 min ago:
> 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. [1] This feature was created as a direct
response to automated formatters like Prettier!
URI [1]: https://git-scm.com/docs/git-blame#Documentation/git-blame.txt...
zbycz wrote 2 hours 27 min ago:
Wow! Definitely will use, when enforcing new eslint rules. Thanks for
sharing this, i just love git :)
rendall wrote 29 min ago:
github uses it too
URI [1]: https://docs.github.com/en/repositories/working-with-files...
foofoo12 wrote 4 hours 20 min ago:
My love for Prettier went to hate when they started fucking up my
parenthesis in calculations. Still an open issue from 2017:
URI [1]: https://github.com/prettier/prettier/issues/187
moring wrote 3 hours 53 min ago:
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)
Guillaume86 wrote 41 min ago:
They would obviously fix it pretty quick if you reported something
like that, the still open github issue is about pure
styling/readability issue...
lifestyleguru wrote 4 hours 16 min 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 wrote 4 hours 6 min 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 wrote 2 hours 14 min 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.
dSebastien wrote 6 hours 59 min ago:
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 wrote 6 hours 24 min 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 wrote 5 hours 18 min 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.
TranquilMarmot wrote 3 days ago:
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.
CaptainOfCoit wrote 5 hours 6 min ago:
Sounds similar to my personal history of adopting StandardJS ( [1] )
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?
URI [1]: https://github.com/standard/standard
nxrabl wrote 59 min ago:
Standard always struck me as kind of scummy - it tries to present
itself as something bigger than what it really is, which is a tiny
CLI wrapper around one guyâs ESLint config. You have to scroll
way down the FAQ section before ESLint even gets mentioned. The
author is just squatting on the âstandardâ namespace and using
it to blag his way into relevance. Think how much more good it
would do if the sponsors of this project were actually supporting
ESLint directly instead of this useless middleware.
normie3000 wrote 6 hours 43 min ago:
> format-on-save
A dystopian feature!
jjj123 wrote 3 hours 12 min 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 wrote 4 hours 47 min ago:
Fight the power, setup format on checkout with your own rules.
whstl wrote 6 hours 34 min ago:
I'll do one better: In the recent teams I worked, we even had
"organize imports on save".
DanielHB wrote 7 hours 42 min 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.
throw45524947 wrote 19 min ago:
I've recently worked for a company that had no linter and no
formatter. It was Java backend, but we have those tools too :) My
first PR received 70 comments, 98% was nit-picking. Things like
"Rename `MyDomainEntity source` to `MyDomainEntity myDomainEntity`"
(it was a MapStruct mapper).
I was also asked to remove a simple parent class that I used (in
tests!) to reduce duplicated code, something like
`MyNewFeatureBaseTest`, because Create, Get, Update, Patch, Delete
test classes where sharing some functionalitites.
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"?
whstl wrote 6 hours 34 min 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.
Hasnep wrote 2 hours 59 min ago:
Which tools are you using that allow custom linter rules? I'd
like to try this on some of my repos
whstl wrote 2 hours 17 min 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 wrote 2 hours 21 min ago:
eslint and biome allow custom lint rules and it is not that
hard to write new ones yourself.
harimau777 wrote 3 hours 18 min 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.
schwartzworld wrote 5 hours 10 min 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 wrote 4 hours 2 min 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 wrote 3 hours 8 min 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 wrote 3 hours 14 min 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.
DIR <- back to front page