80 characters (plus or minus 10) has a justification outside the history of teletypes and VT100s: that's the optimum for readability.
Otherwise, there are good ideas, in the talk, but this particular one rubbed me in the wrong way.
Breaking up a sentence over multiple lines can TOTALLY change how it's interpreted by the computer.
Using methods to circumvent this which allow you to have a computer interpret two lines as if it's a single line can confuse and change how it's interpreted by the programmer, at least momentarily.
Refactoring your code to ensure it never exceeds 80 characters can ALSO make code harder to read, especially in modern languages that tend to be more verbose than what was seen in the TTY days.
Expanding the limit to even 120 characters and aiming the average line to be significantly shorter allows you to have a more consistent readable style across languages where you aren't doing nearly as much weird crap to force source code to fit an arbitrary character limit. You STILL have to do quite a bit of rewriting to force code to fit 120 characters, but this may be worth the readability tradeoff.
Of course, they were never around 6 months later to prove if they still understood their gobbledygook then. They never had to refactor anything.
I have very rarely encountered a piece of code that would be hard to fit into 80 characters width while being readable. In fact, if done correctly, it forces you to break stuff up into manageable pieces and simple statements, to be explicit and often verbose.
But if this runs counter to a messy, ego-centric style a developer is used to and there’s no one to reign them in, it’s what you get.
user = manager.getUser()
mobile = user.getPhone(PhoneType.mobile)
area = mobile.getAreaCode()
area = manager.getUser().getPhone(PhoneType.mobile).getAreaCode() area = manager
.getUser()
.getPhone(PhoneType.mobile)
.getAreaCode();
I can empathise - when I started out I was all about clever code. But the older I get, and the more code I have to deal with, the more I value simplicity.
The 80 character limit is a really good signal that my code is too complex and needs simplifying. The most common occurrence these days is when I have too many arguments to a function, and either need to curry it or create an options data struct. My code is cleaner for this.
And there have been many, many, times that a comment from past me to 3-months-later me has saved me an hour of reading. Code, even intentionally simple code, is not as self-documenting as it appears to be when we're writing it.
There are two reasons for lines to get long: (1) cleverness, or (2) long names.
I used to hate long names, and still can't stomach most Java code. But I've learned that if you want understandable code, you can either have short names and long comments, or long names and hardly any comments. (But please, no longer than is necessary to communicate what needs to be communicated. addKeyAndValueToTable() tells you nothing of use over add() or put(). setForwardingPointerWhileTenuring() does communicate some important things that set() or setPtr() would not.)
I stick to VerbNoun function naming, and usually code in Go where short (1-letter short) variable names are idiomatic.
If I can't VerbNoun a function, then I probably need to rethink it.
Part of the reason I don't do anonymous/lambda functions too happily - it's actually harder to read a stack of anonymous functions than a stack of VerbNoun named functions.
Many other times the comments have made understanding the code harder.
My motto is that comments are the only part of the code you can be sure are not tested. At best they record the intent of an author at some unknown point in the past.
This probably says something about the priority the teams you worked with put on documentation. Write once and never update?
Expanding to 120 character lines means I can only have one column of code on my laptop screen at the same time and only if I maximise the window. It also means I can't have 3 columns on my desktop screen. And no, horizontal scrolling or line wrapping is not an option, it's a nightmare.
That said, I don’t think it should be a hard limit and it’s fine if a lines a bit over, +/- 10 like you said. Certainly not something that we should contort into multiple lines just to keep under a hard limit. Unfortunately, a few auto formatters only do hard limits - it’d be interesting to see how an acceptable interval around the limit would work.
Plus, I’ve noticed the limit makes more of a difference for comments than code so I try to keep comments under that. The written word appears more sensitive to line length.
Or in other words, by formatting the code more like a human than dumping the source tree with a blind set of rules. If Copilot is possible then so is an AI model able to consider how code actually looks on the screen.
PEP8's and Google style guide's limits of 79 and 80 are way to narrow for a language with 4 space identation. However PEP says that "it is okay to increase the line length limit up to 99 characters" while Google's 80 is just a soft limit that can be broken in certain cases like long URLs.
But as far as I known this have only been researched for reading prose. I doubt the result will translate directly to reading source code, which is read in a completely different way.
Also: the optimal line width for prose seems to be 50-75 characters (including whitespace). Source: https://baymard.com/blog/line-length-readability
Assuming you're using a language where indentation is either mandated (e.g. Python) or recommended (e.g. C with "One True Braces"), with 4-spaces indentation (here again, no experimental evidence, but this seems to be the norm nowadays), and you don't abuse cyclomatic complexity in your functions / methods, you have let's say between 2 and 4 indents on the left so 80 is close to the optimum.
Note: up to 100 is probably still OK from a readability POW. But this assumes that all readers are able to increase their window size from the default 80. That's probably true for people using GUIs, but may still be problematic for people with sight issues (e.g. people over 50 or with more serious medical conditions...).
Code is not like books: most lines will be shorter than the "limit", there's indentation, you're typically reading monospaced characters on a screen, and you have syntax highlighting, etc. So, bumping the length up to 80 characters is still okay, as is the occasional outlier. But regularly writing 100-120 characters-long LoCs will definitely impact readability.