80 columns wide? 132 columns wide?

[Martin Rinehart]

In a review of seven conventions documents I found two that addressed
file width. Crockford says 80; Nextapp says 132.

I like 80 so I can see several files at once on my wide monitor.
Thoughts?

 

[Joost Diepenmaat]

In a review of seven conventions documents I found two that addressed
file width. Crockford says 80; Nextapp says 132.

I like 80 so I can see several files at once on my wide monitor.
Thoughts?

80 is "traditional" - it's the width of many of the original
terminals. 132 is a bit wide, and IMHO just about the widest you can go
and still be readable. I think 80 is a good width to shoot for, but the
occasional line can go a bit wider than that if that works/reads better
(if you've got a few nested long method names, for example).

 

[Martin Rinehart]

80 is "traditional" - it's the width of many of the original
terminals. 132 is a bit wide, and IMHO just about the widest you can go
and still be readable. I think 80 is a good width to shoot for, but the
occasional line can go a bit wider than that if that works/reads better
(if you've got a few nested long method names, for example).

My editor wraps overwidth lines intelligently. Is this now a common
editor feature? If so, we should give any convention re width the
boot.

P.S. I used to write for a magazine with a 52 char column max.

 

[Dr J R Stockton]

In comp.lang.javascript message <26406335-3132-4db5-b102-af9828d3cc47@e1
g2000pra.googlegroups.com>, Fri, 31 Oct 2008 14:34:23, Martin Rinehart

In a review of seven conventions documents I found two that addressed
file width. Crockford says 80; Nextapp says 132.

I like 80 so I can see several files at once on my wide monitor.
Thoughts?

Use 72, as the FAQ recommends; then you can post your code to News with
no additional problems.

 

[Dr J R Stockton]

In comp.lang.javascript message <382f68ba-ae9b-4ebb-b4d1-dd6e0fd865eb@l3
3g2000pri.googlegroups.com>, Sat, 1 Nov 2008 04:23:06, Martin Rinehart

My editor wraps overwidth lines intelligently. Is this now a common
editor feature? If so, we should give any convention re width the
boot.

One should consider, if necessary, the worst case editor, not the best
case. However, the convention applies to what is transmitted, and not
to the means of generating or displaying it.

Don't try to change standards until you understand them, and the
reasoning behind them, fully.

It's a good idea to read the newsgroup c.l.j and its FAQ. See below.

 

[Jeremy J Starcher]

On Sat, 01 Nov 2008 16:04:19 +0000, Dr J R Stockton wrote:

[Regarding line length]

Use 72, as the FAQ recommends; then you can post your code to News with
no additional problems.

And spaces instead of tabs.

 

[Joost Diepenmaat]

My editor wraps overwidth lines intelligently. Is this now a common
editor feature? If so, we should give any convention re width the
boot.

Since the line width is intended to make the code easy to READ, I should
think it's not very relevant how smart your particular editor is (and
besides, any editor automatically wrapping JavaScript had better be
very careful since newlines are pretty significant in JS).

 

[John W Kennedy]

132 came from the era of line printers. The IBM 3211 was the first that
I encountered that would handle this width. It remains a number that I'm
highly likely to chose in window widths (my command prompt, for example)

It goes back to the IBM 1403, which originally came in either 100 or 132
(120 was a later option). Almost everyone who got a 1403 went with 132,
and it became the line-size norm for decades. (The 1403 was a top seller
from 1960 to 1979, because the 3211, though twice as fast, was also
twice as expensive; as a rule, only companies with big printing farms
went with the 3211. Even the machine that finally replaced the 1403, the
3203, used a lot of 1403 parts.)

132 was also available in the second-generation 3270 screens, where it
was mostly used by programmers to look at printouts.
--
John W. Kennedy
"The pathetic hope that the White House will turn a Caligula into a
Marcus Aurelius is as naïve as the fear that ultimate power inevitably
corrupts."
-- James D. Barber (1930-2004)

 

[Tim Slattery]

80 Columns was the width of the punched card (I still keep a small stock
of the IBM 5081 version, left over from when I stopped using them).

Yup, absolutely right. Herman Hollerith's original punch cards for a
late 19th century census were 80 columns wide, and that set a standard
that lasted many decades. The "IBM cards" that everybody used in the
1950s / 1970s were actually 80-character Hollerith cards. The original
character-mode, CRT terminals were 80-characters wide, to mimic the
cards.

Fanfold printer paper from the same era, and the line printers that
used it were 132 characters.

 

[Martin Rinehart]

besides, any editor automatically wrapping JavaScript had better be
very careful since newlines are pretty significant in JS).

Sloppy statement by me. My editor wraps long lines in its display of
them, not by inserting newlines. I'm looking at line 440 of an HTML
file. It continues down my 80 column screen for four lines, before
getting to line 441.

 

[Martin Rinehart]

One should consider, if necessary, the worst case editor, not the best
case. However, the convention applies to what is transmitted, and not
to the means of generating or displaying it.

Conventions should be for the worst case, not the common case?

It's a good idea to read the newsgroup c.l.j and its FAQ. See below.

Should I add the newsgroup FAQ to my list of conventions documents? In
this particular that would have been helpful.

Martin

 

[Dr J R Stockton]

In comp.lang.javascript message <qp2ug45b569qa128g04n7dhc9e5uqlimr5@4ax.

Yup, absolutely right. Herman Hollerith's original punch cards for a
late 19th century census were 80 columns wide, and that set a standard
that lasted many decades. The "IBM cards" that everybody used in the
1950s / 1970s were actually 80-character Hollerith cards. The original
character-mode, CRT terminals were 80-characters wide, to mimic the
cards.

Fanfold printer paper from the same era, and the line printers that
used it were 132 characters.

It's all very well saying that; but it is readability that is important.
Look at the better newspapers; look at ordinary books; look at
Government bumph - almost all use fewer than about 72 characters per
line.

Longer lines are more convenient in writing programs, but not
necessarily in reading them.

Hardware limits should be considered as no more than an upper bound; not
to be exceeded, but not necessarily to be approached.

 

[Joost Diepenmaat]

Sloppy statement by me. My editor wraps long lines in its display of
them, not by inserting newlines. I'm looking at line 440 of an HTML
file. It continues down my 80 column screen for four lines, before
getting to line 441.

Ah ok, I was wondering about that

I still think that code for public inspection should be wrapped at about
72 - 100 chars though, just because "manually" formatted code tends to
be more readable.

 

[Dr J R Stockton]

In comp.lang.javascript message <c48de7a5-d90b-4e41-a702-131d8c387db5@b3
1g2000prb.googlegroups.com>, Mon, 3 Nov 2008 12:22:39, Martin Rinehart

Conventions should be for the worst case, not the common case?

I wrote that one should consider the worst case. Having considered it,
one can then consider whether the convention should allow for it. If it
is eliminated from significance, then recurse.

 

[Dr J R Stockton]

I still think that code for public inspection should be wrapped at about
72 - 100 chars though, just because "manually" formatted code tends to
be more readable.

In this context, one should not use the word "wrapped". If one does so,
it may be interpreted as meaning by some automated process, which for
code is rarely likely to be satisfactory - it will probably break
unwisely, it is unlikely to indent the broken-off part correctly.

Use "... should be written with a margin at 72-100 chars ..." or similar
instead.

 

[Martin Rinehart]

Look at the better newspapers; look at ordinary books; look at
Government bumph - almost all use fewer than about 72 characters per

True for newspapers, but I just counted chars in two books: about 80.

 

[John W Kennedy]

Yup, absolutely right. Herman Hollerith's original punch cards for a
late 19th century census were 80 columns wide, and that set a standard
that lasted many decades. The "IBM cards" that everybody used in the
1950s / 1970s were actually 80-character Hollerith cards. The original
character-mode, CRT terminals were 80-characters wide, to mimic the
cards.

Not so. Hollerith's original cards went through several formats, finally
settling on 45 columns with round holes. In 1928, IBM changed to narrow,
rectangular holes (which could be better read by the new brush
technology) and 80 columns. At about the same time, Remington Rand,
IBM's only meaningful competitor, kept 45 physical columns and round
holes, but went to two tiers, for 90 effective columns. (In 1969, IBM
introduced miniature, three-tier, 96-column cards for the System/3,
returning to round holes for optical reading.)

Further note: the IBM 704 computer read cards in binary, as two 36-bit
words for each row. Two times 36, of course, is 72, not 80. The card
reader could be wired to read any 72 columns, but 1-72 was, obviously,
the most common. FORTRAN was originally designed for the 704, and
consequently made no use of columns 73-80. Programmers grew into the
habit of using those columns for card sequence numbers, so that a
dropped deck could be put back into order. This convention immediately
became so popular that, for the duration of the punched-card era,
virtually all compilers, interpreters, etc., for virtually all
languages, utilities, etc., were normally set to use only columns 1-72;
if they paid attention to columns 73-80 at all, it would be only to
check for ascending numbers and print a warning if the sequence should
be wrong.