5 ms·

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 characte

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 https://go.dev/play/p/cKMKnFwT8tq

1letterunixname 3y ago
Line length with modern toolchains is too often stylistic bikeshedding with awkward limits stuck in 1975 cargo culted from the VT52. My external monitor can legibly display 637 x 81 while my laptop does 217 x 63. The largest barely legible terminals with tiny fonts are 3x the size. Around 100 is a sane minimum while 160 is a sensible upper limit. There's no specific limit other than to prevent poor coding technique, illegible code, or inclusions of generated or minified atrocities.
deleted 3y ago
[deleted]
preommr 3y ago
Then just change it in the prettier config. 80 characters is a really good default. I have an extra wide monitor, and with 2 side panels open in my IDE, that's the perfect length.
- pigeonhole123 3y ago
  It will then force longer lines, which is even worse.
atom_arranger 3y ago
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.
- nicoburns 3y ago
  It should put more weight on the length that the author has original authored it as. So between "always break" and "always expand" there should be an area of "leave it however it already is".
  - zeroonetwothree 3y ago
    Prettier needs to be consistent regardless of the original input. Otherwise it won’t really work well.
    - nicoburns 3y ago
      I don't think it does. Plenty of code formatters are not completely, and work just fine.
- pigeonhole123 3y ago
  It can safely ignore the line length, gofmt does this and I've never heard anyone complain about it. The VSCode formatter also doesn't touch line breaks and it works fine. Last time I looked into it, the only reason I can't turn it off is that Prettier works off an AST that doesn't keep the line breaks that the user put into the code at all, and it "rebuilds" the whole code from this AST. The problem is not the diff per se, the real problem is that I can't find a configuration of Prettier where I can have long lines where it makes sense and short ones where that makes sense.
tuetuopay 3y ago
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.
- nicoburns 3y ago
  I don't understand the hate for "kilometer-long" lines (say in the 120-200 char range). My screen is much wider than it is long, so having longer lines allows me to fit more code onto the screen at once (which is fantastic for readability). Also, sometimes the extra content is uninteresting. And it makes sense to hide it away where it's only sometimes seen.
  - tuetuopay 3y ago
    I'm modern, and a 120 char line is not kilometers long. It's in the range for modern stuff (yep, I'm an advocate for dropping 80 chars). km long lines start at 200 chars IMHO. To me, too long lines actually hinders readability: - kilometer-long lines makes your eyes travel a lot more to read what is happening. travel is not that an issue, but context is. it is quite hard to get at a glance e.g. the argument list of a function. or know if e.g. a specific parameter is in the argument list. - I almost never have my editor's viewport set to kilometers. It's usually in the ~110 chars range to fit multiple files at once (two side-by-side on 1080p, three on 1440p). Not that I am editing three files at once, but I'm usually editing the middle one with other files on the side for context and reference. In such a setup, the line ends up wrapped anyways, but with ugly wrapping that does not match indentation and in the middle of words. As for hiding it, that's what editor folds are for. Anyways, I guess we found bikeshedding topic not solved by formatters :D
  - WorldMaker 3y ago
    Wider screens can also be used to have more code files or sections of the same file side-by-side. You can get two, three, sometimes four 80-char width files very nicely side by side.
- 3y ago
j1elo 3y ago
Funny thing: I recently learned Go, coming from doing some TypeScript and the refreshing feel that was discovering Prettier. I really miss that gofmt applied some limit to line length. In TS I just write a too long line, and Prettier reformats it into a sensible set of consecutive lines, I don't even have to think if breaking before or after this or that parentheses or bracket. With Go, I have to, and I'd rather not.
warp 3y ago
Couldn't you just set the "printWidth" in .prettierrc.json to something super long?
- laurent123456 3y ago
  In that case prettier will put the code you formatted over multiple lines into one giant line spanning multiple screens. This is especially relevant for method chaining.
solatic 3y ago
`lineWidth` is actually one of the available options in the biome formatter: https://biomejs.dev/formatter#configuration https://biomejs.dev/formatter#configuration
- nicoburns 3y ago
  Yeah, but if you increase the lineWidth then it will make all your lines that long, even if you don't want them to be. There is no possibility for variability of line lengths depending on the code at hand.
pkilgore 3y ago
Why throw out the tool when you can have the tool ignore [1] whatever is outside the common case? [1] https://prettier.io/docs/en/ignore.html https://prettier.io/docs/en/ignore.html
- pigeonhole123 3y ago
  My approach is to just not use Prettier but instead use the much more well behaved formatter included in VSCode. I don't have time to fight the formatter and I don't like having these "cheat code" comments all over my code

1letterunixname 3y ago

Line length with modern toolchains is too often stylistic bikeshedding with awkward limits stuck in 1975 cargo culted from the VT52. My external monitor can legibly display 637 x 81 while my laptop does 217 x 63. The largest barely legible terminals with tiny fonts are 3x the size. Around 100 is a sane minimum while 160 is a sensible upper limit. There's no specific limit other than to prevent poor coding technique, illegible code, or inclusions of generated or minified atrocities.

deleted 3y ago

[deleted]

preommr 3y ago

Then just change it in the prettier config. 80 characters is a really good default. I have an extra wide monitor, and with 2 side panels open in my IDE, that's the perfect length.

pigeonhole123 3y ago
It will then force longer lines, which is even worse.

atom_arranger 3y ago

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.

nicoburns 3y ago
It should put more weight on the length that the author has original authored it as. So between "always break" and "always expand" there should be an area of "leave it however it already is".
- zeroonetwothree 3y ago
  Prettier needs to be consistent regardless of the original input. Otherwise it won’t really work well.
  - nicoburns 3y ago
    I don't think it does. Plenty of code formatters are not completely, and work just fine.
pigeonhole123 3y ago
It can safely ignore the line length, gofmt does this and I've never heard anyone complain about it. The VSCode formatter also doesn't touch line breaks and it works fine. Last time I looked into it, the only reason I can't turn it off is that Prettier works off an AST that doesn't keep the line breaks that the user put into the code at all, and it "rebuilds" the whole code from this AST. The problem is not the diff per se, the real problem is that I can't find a configuration of Prettier where I can have long lines where it makes sense and short ones where that makes sense.

tuetuopay 3y ago

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.

nicoburns 3y ago
I don't understand the hate for "kilometer-long" lines (say in the 120-200 char range). My screen is much wider than it is long, so having longer lines allows me to fit more code onto the screen at once (which is fantastic for readability). Also, sometimes the extra content is uninteresting. And it makes sense to hide it away where it's only sometimes seen.
- tuetuopay 3y ago
  I'm modern, and a 120 char line is not kilometers long. It's in the range for modern stuff (yep, I'm an advocate for dropping 80 chars). km long lines start at 200 chars IMHO. To me, too long lines actually hinders readability: - kilometer-long lines makes your eyes travel a lot more to read what is happening. travel is not that an issue, but context is. it is quite hard to get at a glance e.g. the argument list of a function. or know if e.g. a specific parameter is in the argument list. - I almost never have my editor's viewport set to kilometers. It's usually in the ~110 chars range to fit multiple files at once (two side-by-side on 1080p, three on 1440p). Not that I am editing three files at once, but I'm usually editing the middle one with other files on the side for context and reference. In such a setup, the line ends up wrapped anyways, but with ugly wrapping that does not match indentation and in the middle of words. As for hiding it, that's what editor folds are for. Anyways, I guess we found bikeshedding topic not solved by formatters :D
- WorldMaker 3y ago
  Wider screens can also be used to have more code files or sections of the same file side-by-side. You can get two, three, sometimes four 80-char width files very nicely side by side.
3y ago

j1elo 3y ago

Funny thing: I recently learned Go, coming from doing some TypeScript and the refreshing feel that was discovering Prettier. I really miss that gofmt applied some limit to line length. In TS I just write a too long line, and Prettier reformats it into a sensible set of consecutive lines, I don't even have to think if breaking before or after this or that parentheses or bracket. With Go, I have to, and I'd rather not.

warp 3y ago

Couldn't you just set the "printWidth" in .prettierrc.json to something super long?

laurent123456 3y ago
In that case prettier will put the code you formatted over multiple lines into one giant line spanning multiple screens. This is especially relevant for method chaining.

solatic 3y ago

`lineWidth` is actually one of the available options in the biome formatter: https://biomejs.dev/formatter#configuration https://biomejs.dev/formatter#configuration

nicoburns 3y ago
Yeah, but if you increase the lineWidth then it will make all your lines that long, even if you don't want them to be. There is no possibility for variability of line lengths depending on the code at hand.

pkilgore 3y ago

Why throw out the tool when you can have the tool ignore [1] whatever is outside the common case? [1] https://prettier.io/docs/en/ignore.html https://prettier.io/docs/en/ignore.html

pigeonhole123 3y ago
My approach is to just not use Prettier but instead use the much more well behaved formatter included in VSCode. I don't have time to fight the formatter and I don't like having these "cheat code" comments all over my code