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):
I agree with that. But the limit should be 120 or 160, not 80 (and my formatter should allow me to set a wider limit like that without making all my lines extra-wide - I want to be able to put things on one line where appropriate and not where it's not).
> I definitely buy the tiny amount of "noise" it brings
Tiny? It makes a lot of my code 3-5x as long. And often breaks things in weird places. This is IMO not a small reduction in readability.
My least favorite though no limit + soft wrapping, the philosophy being the code adapts to the user, but in actuality means the file looks completely different based on your monitor and setup removing visual aid to code navigation and familiarity.
I get it, 160 looks OK and fits into a 4K display without any other windows open. I believe working with dual panes is more productive, so I'll always stand behind shorter line lengths that allow for it.
Even Rust, a modern language that is usually said to collect the best learnings from the industry, thankfully chose a conservative and sensible 100 chars limit by default.
Do you mean entire files are made 3-5x as long or just individual lines every now and then?
I don't see a reason to enforce this strictly. The goal is readability, the max line length is an approximate proxy for that.
I ignored this point on purpose, to be more succint. But yes, it could be possible to have a soft limit (e.g. 80, or 100) and then you would have to set a hard limit (say, 85 or 105). But in the end you'd end up having someone who complains because their beautiful line was 84 chars and after adding the closing paren and the semicolon, it got wrapped into something that they don't like because subjective tastes.
So in the end, we just moved the goalpost +5 chars.
I think discussion on the perfect limit on public forum is non-sense. It might be slightly less non-sense to discuss it with your team, but even that I think it is bike-shredding most of the time, unless the entire team for some reason (like they share the same equipment setup and happen to have same preference) overwhelmingly share the sentiment.
It kind of sounds like you're promoting your own setup.
The funny thing I see the most is that people with these crazy widescreen monitors still maximize just one window, with just one file open. Not sure why, maybe for focus?
On my screen with 1920x1080, 2 side-by-side panels can fit 100 chars, but only if the sidebar is hidden (project layout, list of open files, that kind of stuff).
On my laptop, 2 side-by-side files won't fit if they exceed 90 chars.
I just don't want to concede to those devs who use a single editor pane with an ultrawide monitor, and believe that everybody must work like they do.
With regards to the whitespace issue, that's down to the line length rules used I think. It's also down to the diff viewer how to show it, not the formatter.
For example, if someone changes:
function isUserBanned(username) {
return db.findUserByName(username)?.banned;
}
function isUserBanned(username) {
return
db.findUserByName(username)?.banned;
}
Also, adding braces from the start means that adding one new line of code is a one-line patch, instead of a four-line one - I do that for the same reason that I always put trailing commas on my array definitions
On the flipside, having three trivial early-return ifs at the beginning of a function will become 9 lines long with braces instead of 6 (or just 3, when doing single-line ifs). Very often, such cases never expand to multiple lines in the future.
I don't think many people who are serious about high "signal to noise" code formatting are supportive of the design decisions prettier makes. e.g. the staggered import lines, left-shifting and up-shifting of implementation details, not allowing trailing comments on the same line
We can have consistent formatting and also avoid tons of visual noise that prettier produces... I've wanted to build a competing solution for awhile, but never made the time for it. Perhaps Anthony's project achieves that... I'll give it a try!
But, as well as the issue with line noise, it also encourages patterns that I think detract from code comprehension. It favours expressions over statements and even now, it’s not easy to set a breakpoint in the middle of one, so you end up rewriting into statements just so you can step through.
It will favour deeply nested ternary statements in react so your code reads more like a tree with densely tangled roots.
It will favour shorthand syntax for optionally merging properties into an object, which basically relies on a quirk of the splat operator.
There is fuck all standard library to speak of without pulling in an insane amount of dependencies, but surely stuff like deep merge and compact should be provided out of the box?
I've never had an issue setting an inline breakpoint[1] in VS Code, is it an issue in other IDEs?
[1] https://code.visualstudio.com/Docs/editor/debugging#_inline-...
(Most people I know just use console.log - print debugging works all the time but I like having a repl)
That's the opposite of what they claim: https://prettier.io/docs/en/option-philosophy
- 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"]`
For the record, prettier can also be extended to support more languages[3].
[1] https://eslint.org/docs/latest/use/command-line-interface#--...
It's annoying, but not a reason to throw the baby out with the bathwater.
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.
- filter: /\.(jimmy|jimbo|jeremiad)$/
+ filter:
+ /\.(jimmy|jimbo|jeremiad|james)$/
If you prefer a CLI tool, check out https://github.com/Wilfred/difftastic. It supports more languages, but doesn't recognize when code has been replaced by an equivalent version ("invariances"). So it will show some changes (e.g. replacing a character in a string with an escape sequence) even though they are technically equivalent.
You will - every time you extend a line which now exceeds the limit.
Would it be realistic to expect a solution for this issue now that "prettier needs to step up it's game"?