S
Steven D'Aprano
The accepted rule in print is that lines of prose should be between 45
and 90 characters, with 66 being ideal for readability. Code is not
prose, and the combination of fixed-width and much more variable line
length aids readability, but however it came about, ~80 does seem to
more or less work as a limit.
On the other hand, code is typically *much* harder to understand than
normal prose.
On the third hand, the "chunks" of semantic meaning in code is
significantly greater -- you can often ignore 99% of the code and just
skim past it, and so not even notice long line lengths until you get to
the specific few lines you care about. But once you reach the lines you
care about, or *might* care about, horizontal space is costly and
vertical space is cheap.
So reading code often has two distinct phases: skim and inspect. When
skimming, vertical space is at a premium, and you want to fit as much
code as possible in as few lines as possible. When inspecting code
closely, you want to fit as little code as practical in each line. So
there's a trade-off.
But for anything but the most horribly obfuscated code, it is much easier
to identify bits of code that are irrelevant to your problem than to
identify which bit of code is specifically causing the bug. So skimming
is inherently easier than close study (well duh). Consequently it is wise
to optimise your code layout for the hard parts, not the easy parts, and
so you should treat vertical space is cheaper than horizontal space, and
try to keep your line length down.
And note that, even when writing, most of your time is problem spent in
writing what is already there. Coding is rarely like typing out dictation.