On 80 columns should (not) be enough for everyone

[Ulrik Mikaelsson]

FWIW: Here's my two cents; (Non-Phobos participant, so feel free to
click delete now)

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

I would rather like to hear whether any mathematicians ever insert
hard-breaks into their equations just "to not get them too wide".

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. When the code
exceeds 90 columns, I try to look for:
 * local variable names that can be shortened without breaking their
descriptiveness.
 * sub-expressions in the line, which can be reasonably be extracted
into separe pre-computed variable. (Which also increases readability
of the code by itself.)
 * unnecessary nested depth in the function, and try to either
refactor parts out to separate functions, or refactor the function to
be more pass-based rather then nested.

One special-case which often cause problems, is function-calls,
especially "method"-calls. Roughly lines like: (note 3-level leading
indent)
            otherObj1.doSomethingSensible(otherObj2.internalVariable,
this.config, this.context);

At this point, I can see two obvious alternatives;
            otherObj1.doSomethingSensible(otherObj2.internalVariable,
this.config,
                                          this.context);
vs.
            otherObj1.doSomethingSensible(otherObj2.internalVariable,
                                          this.config,
                                          this.context);

Both have advantages and problems. In the first alternative, you might
miss the second argument if reading too fast, and in the second
alternative, the vertical space can be quickly wasted, especially if
the line get's just slightly too long due to many small arguments.
(I.E. debug-output of many short-named local variables.) In these
cases, I usually just leave it to overflow. That will
 * hint to the reader that it's still just one single function-call
 * arguments won't be missed
 * not waste unnecessary vertical space
 * it's up to the code-viewer to determine whether a line-wrap is
actually needed, which it might even indicate using a wrap-marker in
the margin (not possible with a manual line-break).

For other common long-line sources like enums, array literals etc, I
usually block-format and insert line-breaks as usual to not exceed 90
columns wide.

My guess is, if I worked enough with long mathematical expression, I
would use roughly the same guidelines.

/ Ulrik

(*doh* that was probably more than 2 cents worth.)

2011/1/30 Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>:
> On 01/30/2011 12:27 PM, Walter Bright wrote:
>>
>> Andrej Mitrovic wrote:
>>>
>>> 80 columns
>>> wasn't determined by some scientific method to be a good size for
>>> code, it's
>>> a product of limitations of the older generation hardware.
>>
>> 80 columns came from how many characters would fit on a standard size
>> 8.5*11 sheet of paper. Even punch cards followed this precedent.
>>
>> That paper size has stood the test of time as being a comfortable size
>> for reading. Reading longer lines is fatiguing, as when one's eyes
>> "carriage return" they tend to go awry.
>>
>> You can see this yourself if you resize and reflow a text web site to be
>> significantly wider than 80 columns. It gets harder to read.
>
> Also: pick a random book or newspaper and count the characters in a line.
> They range between 60 and 80, counting for about 10 words per line. This has
> been the case ever writing systems have been invented. It is a fallacy to
> assume that 80 has anything to do with the first monitors. In fact, it's the
> opposite - the monitors were conceived following a universal human constant.
>
> One funny thing is that at my employer (where each and every employee has a
> 30" 2560x1600 monitor) everything is under constant debate, starting with
> which email server and ending with choosing UserId versus UserID. Nobody and
> not once has debated the 80 column rule.
>
> Phobosians have voted with their fingers. Long lines in Phobos are rare and
> the result of lack of enforcement, not a stylistic choice. Jonathan simply
> didn't know about that, and has graciously agreed to align to that
> convention (thanks!).
>
>
> Andrei
>