On 2021-02-07 22:36, David Mertz wrote:
> Code is READ far more often than it is written!
> Lines more than 80-ish characters impose a rapidly increasing cognitive
> and visual burden with every additional character. Really, starting at
> more like 70 characters. It's not quite exponential in the harm, but
> it's strongly super-linear, after the threshold.
What I'm saying is that there is no reason for that to
constrain the logical length of the number of characters before a line break character. It's precisely because code is read more often than it's written that we should not, at the time of writing it, make these kinds of needlessly detailed decisions about how it's going to look.
When you write code, you should try to communicate to HUMANS even more than to computers. Computers don't care about comments, for example (for most purposes). But humans do. You should use neither too few nor too many, and those you choose should convey what is most important to communicate, above and beyond the code syntax that humans can also understand.
A line of text, in human perception, makes up a unit of understanding. It's not the only unit. Sentences do not usually end where lines do, in prose.
A "logical line" of code in Python or other languages may need more than 80 characters. Python is better here than languages that tends to use very long identifiers, for example. But it is an important service to your readers to break lines at "clauses" that aid their focus and organize the small cognitive breaks between physical lines. You know about parens and trailing backslashes just as well as I do, and about refactoring; there are many ways to fulfill your ethical duties towards readers.
A code editor, or even a smart formatter like black, simply cannot make those decisions as conscientiously as a human programmer can (if the latter feels compunctions). Yes, the tool can use fairly sophisticated heuristics, but you have an obligation to treat your readers not just "pretty well" but rather the best you possibly can.