Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Birth of Prettier

blog.vjeux.com

Post reply on HN
Print view View original

41–50 of 57 posts

Re: Birth of Prettier

#41

Post by whstl »

Hasnep wrote: post #33
whstl wrote: post #6

Earlier quoted context omitted.

+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…

Which tools are you using that allow custom linter rules? I'd like to try this on some of my repos

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.

Re: Birth of Prettier

#42

Post by ezarowny »

maratc wrote: post #15
lifestyleguru wrote: post #14

Earlier quoted context omitted.

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".

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!

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.

Re: Birth of Prettier

#43

Post by NoSalt »

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.

Re: Birth of Prettier

#44

Post by nxrabl »

CaptainOfCoit wrote: post #11
TranquilMarmot wrote: post #2

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…

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 Standa…

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.

Re: Birth of Prettier

#45

Post by Guillaume86 »

moring wrote: post #18
foofoo12 wrote: post #13

My love for Prettier went to hate when they started fucking up my parenthesis in calculations. Still an open issue from 2017: https://github.com/prettier/prettier/issues/187

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 ||…

They would obviously fix it pretty quick if you reported something like that, the still open github issue is about pure styling/readability issue...

Re: Birth of Prettier

#46

Post by rendall »

zbycz wrote: post #38
rendall wrote: post #16

> 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…

Wow! Definitely will use, when enforcing new eslint rules. Thanks for sharing this, i just love git :)

github uses it too

https://docs.github.com/en/repositories/working-with-files/u...

Re: Birth of Prettier

#47

Post by throw45524947 »

DanielHB wrote: post #3
TranquilMarmot wrote: post #2

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…

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…

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"?

Re: Birth of Prettier

#49

Post by DanielHB »

throw45524947 wrote: post #47
DanielHB wrote: post #3

Earlier quoted context omitted.

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…

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 `MyNewFeatureBase…

I am sorry for your experience but I do agree with you, the conventions you were dealing with are bad. It is preferable to avoid conventions that can't be statically enforced specifically to avoid this kind of scenario you are describing.

Re: Birth of Prettier

#50

Post by nicbou »

dleeftink wrote: post #8
dSebastien wrote: post #4

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

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.

The hook is just a safeguard, but ideally your editor should run the same code.
Post reply on HN