On 80 columns should (not) be enough for everyone

[Ulrik Mikaelsson]

2011/1/31 Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>:
> On 1/31/11 11:54 AM, Ulrik Mikaelsson wrote:
>> I'm not sure whether text-books and program-code are really comparable
>> in this respect. When reading books I hardly put much attention to
>> each particular word, while in computer-code, each token is very
>> significant. The "flow" of reading is simply different. If it weren't,
>> we would hardly use hard line-breaks at all, just concatenate
>> statements like we concatenate sentences in text, and use<your word
>> processor>  to format code. Especially, we would not use monospaced
>> fonts and care about "columns".
>
> Well the fact of the matter is that style used in books is very influential.
> People do copy book samples into code and continue working in the same style
> from them. I've been asked for (and released) the source code of all
> snippets in TDPL.

Sorry, maybe I was unclear, I wasn't referring to code-snippets in a
book. I meant the kind of text-books I understood Walter refer to,
that made the basis for 80x25. Think fiction, not programming books. I
absolutely agree there are good UI-design reasons to limit
column-width in these. Commonly such text is also "text-align:
justify", and even broken up into multiple-column layouts to reduce
horizontal scan, but precisely those two things make me skeptical
about just HOW relevant it actually is for computer-code.

>> I would rather like to hear whether any mathematicians ever insert
>> hard-breaks into their equations just "to not get them too wide".
>
> I'm not sure I can qualify as a mathematician but my research is very
> math-heavy. In my thesis (http://erdani.com/research/dissertation_color.pdf)
> I frequently inserted line breaks even when not technically necessary, check
> e.g. eq. 2.16 on page 12.

Thank you, interesting for the topic (although I didn't understand a
thing of the actual math :). I note however that given the very terse
variable-names (as is common in math), the lines don't actually grow
very long. However, where you HAVE chosen to insert line-breaks, is at
equality-operators which I would say is roughly a statement in
programming-language terms. ("A = B" is a statement, while "A+B" is
not.)

Interestingly enough, this is roughly the rule-of thumb I use. Try
hard to keep statements below 90 characters, but don't resort to
manual line-breaks if it's not possible.

>> Personally, I've been a long time on the fence regarding strict
>> line-length, and my current position is:
>>  90 columns is the rule of thumb. 80 columns is often hard to fit
>> using readable names, but 90 columns generally works.
>
> Seems reasonable. Since both Jonathan and Don prefer longer lines, I'm now
> more inclined to increase and/or soften the recommended limit for Phobos.
Actually, writing and reading about it got me thinking. I think the
real value of the 80/90/120/whatever-rule is not really the actual
line-length itself. If that was the case, editors with
auto-indentation could quite easily have additional rules for
automatic code-wraps. The actual value of having the rule is to alert
the coder that something _might_ be sub-optimally expressed. Perhaps D
should have something similar to pylint? Sure, much of the need for
pylint goes away in a statically typed language, but it's also quite
good in diagnosing design by code-complexity measurements. OTOH things
like symbols-per-file, arguments-per-function,
operations-per-function, etc. could be good indicators to quickly spot
hairy code. One could also check for naming-conventions and probably
other cleanliness-aspects as well.