> If the limit is 80, then the limit is 80, not 81.
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.
Do you work with a large team? There is no correct answer for formatting for a team, there is only correct answer for individual person. The line limit 80/120/160 will work for certain people with their setup, but not others. Stuff like using a ultrawide screen with two columns, or code on laptop screen with single column, or code with half screen code editor and half screen browser, etc, there are endless mutation, all of them can benefit from different settings. It is essentially not possible to find the best option for everyone on the team. You may think 120 is the best, but there is no way to prove it. It just worked for you because of your coding setup and preference.
I don't care what the limit is unless it's consistently applied.
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 work on a ruby/ts/js codebase and seem to recall different file extensions having different line lengths. Something like that is annoying but at least it's more consistent within the file extension
Like I mentioned to the sibling parent, 100 is an OK middle ground. 120, or more, is too long already, and 160 is waaaay beyond what I'd consider acceptable. No way you can fit 2 side-by-side editor panes with those line lengths, unless you use a tiny sized font.
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.
I wasn't aware Rust chose a 100 line default. I'll definitely be using this to argue on my teams for why we should stretch the line length limit past 80. Thank you Rust for moving the industry forward
I guess Rust made the same reasoning than Python. For this kind of things, the PEP documents tend to be well based on experience and be a good guideline which even applies for other languages. Check the PEP 8 that I linked in my comment: although they recommend a very conservative limit of 80 (79 actually) it says that if it makes sense, 100 (99) can be used too. And that's from 2001.
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.