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

$20k bounty was claimed

prettier.io

Post reply on HN
Print view View original

61–70 of 345 posts

Re: $20k bounty was claimed

#61

Post by harimau777 »

xdennis wrote: post #24
candiddevmike wrote: post #16

I'm still salty that all my eslint plugins decided to remove perfectly fine linters in lieu of Prettier. I find Prettier to be way too heavy handed and hard to reason about, and yet another tool that I never asked for...

> I find Prettier to be way too heavy handed But that's the purpose of such tools: to stop endless debates about style.

The problem is that style matters and therefore those debates matter. Just because something isn't important to the developers that made Prettier doesn't mean that it's not important to the productivity of other developers.

Re: $20k bounty was claimed

#62

Post by atom_arranger »

pigeonhole123 wrote: post #30
smnscu wrote: post #23

I feel like people complaining about Prettier being "heavily opinionated" are missing the point. Perhaps I'm biased by my decade of using Go, but not having to worry about superfluous stylistic choices is a welcome reduction in cognitive load. (Up to a point I guess, e.g. I'd never put up with K&R-style newline opening brackets).

Prettier is very opinionated about line length which gofmt isn't. That's the only complaint I have and it's bad enough I just refuse to use it. Add one character to a line and enjoy a ten-line diff. Edit: See a contrived example of something gofmt doesn't touch (the behavior I want): https://go.dev/play/p/cKMKnFwT8tq

What should Prettier should do in this case?

I think we can all agree there should be a line length limit, it has to enforce it eventually. You could say “it’s just a couple more characters” until the line is 200 characters long.

Semantic diff is maybe the solution.

Re: $20k bounty was claimed

#63

Post by j1elo »

thenbe wrote: post #33

While it's always great to see performance gains, my largest pain point with prettier was never performance. Instead my only gripe with prettier is the "line wrapping noise" it creates, illustrated here by Anthony Fu: https://antfu.me/posts/why-not-prettier#the-line-wrapping-no... Would it be realistic to expect a solution for this issue now that "prettier needs to step up it's game"?

I'd rather have a strict line length limit, than having my coworker creating objects in lines 150 or 180 chars long.

So we'd end up discussing what is the best choice. I bet I'd also end up discussing those things with Anthony Fu. If the limit is 80, then the limit is 80, not 81.

Come Prettier. No more discussions. I definitely buy the tiny amount of "noise" it brings, in exchange for freeing me from an immense amount of actual noise when having to discuss these things with other people.

EDIT: This comes from a backend dev (C/C++, sometimes Go, recently did some stuff with TypeScript). Prettier was a refreshing discovery, and other languages like Python are able to express the rule very sensibly (albeit I round it and go for 80 or 100):

https://peps.python.org/pep-0008/#maximum-line-length

Re: $20k bounty was claimed

#64

Post by tuetuopay »

pigeonhole123 wrote: post #30
smnscu wrote: post #23

I feel like people complaining about Prettier being "heavily opinionated" are missing the point. Perhaps I'm biased by my decade of using Go, but not having to worry about superfluous stylistic choices is a welcome reduction in cognitive load. (Up to a point I guess, e.g. I'd never put up with K&R-style newline opening brackets).

Prettier is very opinionated about line length which gofmt isn't. That's the only complaint I have and it's bad enough I just refuse to use it. Add one character to a line and enjoy a ten-line diff. Edit: See a contrived example of something gofmt doesn't touch (the behavior I want): https://go.dev/play/p/cKMKnFwT8tq

Funny, that's the one thing I complain about gofmt. I can cope with the occasional diff noise but avoid kilometer-long lines. This is especially noticeable for function names that get long quite quickly.

Also, this means that there is more than one way to format the code, which stands pretty weird given the philosophy of Go.

Re: $20k bounty was claimed

#66

Post by c-hendricks »

thenbe wrote: post #33

While it's always great to see performance gains, my largest pain point with prettier was never performance. Instead my only gripe with prettier is the "line wrapping noise" it creates, illustrated here by Anthony Fu: https://antfu.me/posts/why-not-prettier#the-line-wrapping-no... Would it be realistic to expect a solution for this issue now that "prettier needs to step up it's game"?

Some things overlooked in that blog post for others to take into consideration:

- eslint only works on javascript + typescript (eslint + typescript needs _more_ configuration than eslint + prettier), while prettier works on https://github.com/prettier/prettier/blob/03ebc7869dc9e8f2fc...

- eslint + prettier doesn't need lots of configuration from the user. You add eslint-plugin-prettier and say `"extends": ["plugin:prettier/recommended"]`

Re: $20k bounty was claimed

#67

Post by richardwhiuk »

SamBam wrote: post #59
thenbe wrote: post #33

While it's always great to see performance gains, my largest pain point with prettier was never performance. Instead my only gripe with prettier is the "line wrapping noise" it creates, illustrated here by Anthony Fu: https://antfu.me/posts/why-not-prettier#the-line-wrapping-no... Would it be realistic to expect a solution for this issue now that "prettier needs to step up it's game"?

It's not really an issue if you do a one-time Prettification commit, and then stick to Prettifying automatically thereafter. Then you won't ever see line-width changes mixed in with functional changes. Isn't this an issue with every linter? At some point you're going to have to decide what to do with old code that doesn't match the new style rules.

> Then you won't ever see line-width changes mixed in with functional changes.

You will - every time you extend a line which now exceeds the limit.

Re: $20k bounty was claimed

#68

Post by varrock »

thenbe wrote: post #33

While it's always great to see performance gains, my largest pain point with prettier was never performance. Instead my only gripe with prettier is the "line wrapping noise" it creates, illustrated here by Anthony Fu: https://antfu.me/posts/why-not-prettier#the-line-wrapping-no... Would it be realistic to expect a solution for this issue now that "prettier needs to step up it's game"?

Specifically for reviewing a pull request in GitHub, wouldn't the "Hide whitespace" setting reduce some of this noise? I could be mistaken, though, but that's how I interpreted that setting.

0: https://github.blog/2011-10-21-github-secrets/

Re: $20k bounty was claimed

#69

Post by [deleted] »

jakub_g wrote: post #38
thenbe wrote: post #33

While it's always great to see performance gains, my largest pain point with prettier was never performance. Instead my only gripe with prettier is the "line wrapping noise" it creates, illustrated here by Anthony Fu: https://antfu.me/posts/why-not-prettier#the-line-wrapping-no... Would it be realistic to expect a solution for this issue now that "prettier needs to step up it's game"?

This is indeed the biggest annoyance of mine. I quite often end up rewriting code or changing variable names to counterbalance prettier making code ugly/unreadable.

[deleted]

Re: $20k bounty was claimed

#70

Post by lainga »

SamBam wrote: post #59
thenbe wrote: post #33

While it's always great to see performance gains, my largest pain point with prettier was never performance. Instead my only gripe with prettier is the "line wrapping noise" it creates, illustrated here by Anthony Fu: https://antfu.me/posts/why-not-prettier#the-line-wrapping-no... Would it be realistic to expect a solution for this issue now that "prettier needs to step up it's game"?

It's not really an issue if you do a one-time Prettification commit, and then stick to Prettifying automatically thereafter. Then you won't ever see line-width changes mixed in with functional changes. Isn't this an issue with every linter? At some point you're going to have to decide what to do with old code that doesn't match the new style rules.

Sure you will. Whoops, my regex got too long and now the diff is

    - filter: /\.(jimmy|jimbo|jeremiad)$/
    + filter:
    +     /\.(jimmy|jimbo|jeremiad|james)$/
. And it's not clear where the change is. GP's article has an example of that in a linked tweet.
Post reply on HN