Hacker News Reader

Comment by pigeonhole123 | Hacker News Reader

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

View on HN

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.

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.

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

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.

Line breaks often carry meaning, for example many people like to line up things that belong together but which live on separate lines, and gofmt helps with this. Having many ways to format a given AST (unlike Prettier) is not against the Go philosphy which I would say is "be pragmatic".

If you want a line to be shorter because you as a human find it easier to read that way then you can add a linebreak yourself, and trust that your meaning will be preserved.

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.

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.

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

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

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

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.

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.

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

Prettier needs to be consistent regardless of the original input. Otherwise it won’t really work well.

I don't think it does. Plenty of code formatters are not completely, and work just fine.

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.

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.

It will then force longer lines, which is even worse.

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

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.

Reply on news.ycombinator.com