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

> It makes a lot of my code 3-5x as long.

Do you mean entire files are made 3-5x as long or just individual lines every now and then?

I understand not wanting to bike shed on the actual number but I refuse to accept 80. I simply do not agree that the greybeards with 70s technology got it figured out perfectly in their day and nothing has changed.

> If the limit is 80, then the limit is 80, not 81.

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 agree, actually :)

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.

80 character limit? Are we trying to relive the late 80s. Soon we'll move back to 40 characters. Screens can support higher resolutions now limiting lines to 80 so developers can turn their brains off seems silly. Turn your brain on and learn to filter the noise of 100 characters.

People use ultrawide screen, with half screen dedicated to browser, half screen for code editor, and two columns open in editor. This is very modern setup, and 80 is perfect for it. Don't limit your thinking to your own setup.

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.

> People use ultrawide screen, with half screen dedicated to browser, half screen for code editor, and two columns open in editor. This is very modern setup, and 80 is perfect for it. Don't limit your thinking to your own setup.

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?

Not promoting my setup, but just to point out that 80 is a sensible default, and it is not based / targeted for ancient old rare setups.

100 is OK. But better to wager for 80, so people complain about their preferred 120+, and ending up with an acceptable 100 as a middle ground.

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.

These are web developers. Of course they're going to try to force content into a narrow width view and not let you choose to have a wider view even if it makes perfectly valid sense for the given content. These are usability problems that people aren't allowed to make their own decisions about because the UI designer knows the only right answer. "It makes the content more readable" and all that. /s