By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,741 Members | 2,009 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,741 IT Pros & Developers. It's quick & easy.

80 columns wide? 132 columns wide?

P: n/a
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?
Oct 31 '08 #1
Share this Question
Share on Google+
16 Replies


P: n/a
Martin Rinehart <Ma************@gmail.comwrites:
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).

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
Oct 31 '08 #2

P: n/a
Joost Diepenmaat wrote:
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.
Nov 1 '08 #3

P: n/a
In comp.lang.javascript message <26406335-3132-4db5-b102-af9828d3cc47@e1
g2000pra.googlegroups.com>, Fri, 31 Oct 2008 14:34:23, Martin Rinehart
<Ma************@gmail.composted:
>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.

--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk DOS 3.3, 6.20; WinXP.
Web <URL:http://www.merlyn.demon.co.uk/- FAQqish topics, acronyms & links.
PAS EXE TXT ZIP via <URL:http://www.merlyn.demon.co.uk/programs/00index.htm>
My DOS <URL:http://www.merlyn.demon.co.uk/batfiles.htm- also batprogs.htm.
Nov 1 '08 #4

P: n/a
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.
Nov 1 '08 #5

P: n/a
In comp.lang.javascript message <382f68ba-ae9b-4ebb-b4d1-dd6e0fd865eb@l3
3g2000pri.googlegroups.com>, Sat, 1 Nov 2008 04:23:06, Martin Rinehart
<Ma************@gmail.composted:
>Joost Diepenmaat wrote:
>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.
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.

--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk IE7 FF2 Op9 Sf3
news:comp.lang.javascript FAQ <URL:http://www.jibbering.com/faq/index.html>.
<URL:http://www.merlyn.demon.co.uk/js-index.htmjscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/TP/BP/Delphi/jscr/&c, FAQ items, links.
Nov 1 '08 #6

P: n/a
Martin Rinehart wrote:
In a review of seven conventions documents I found two that addressed
file width. Crockford says 80; Nextapp says 132.
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).
It is also, very roughly, the width of the pages in most regular format
books, so is a line length that people are comfortable reading.

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)

As a programmer, and one who employs verbose comments, I configure my
editor window/font to allow for 190 characters, but if I ever save up
enough for a high-resolution 24" widescreen display, then I'd increase
that to perhaps 240 (which comes from the number of pennies in an old UK
pound). But then I'm the only person who ever sees my source under
normal circumstances.

I can see that a 240 column program might be difficult for others to
read, if they find themselves scanning my code, but my primary goal is
my own efficiency.

--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk
Nov 2 '08 #7

P: n/a
Martin Rinehart <Ma************@gmail.comwrites:
Joost Diepenmaat wrote:
>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.
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).
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
Nov 2 '08 #8

P: n/a
Swifty wrote:
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 nave as the fear that ultimate power inevitably
corrupts."
-- James D. Barber (1930-2004)
Nov 3 '08 #9

P: n/a
Swifty <st***********@gmail.comwrote:
>Martin Rinehart wrote:
>In a review of seven conventions documents I found two that addressed
file width. Crockford says 80; Nextapp says 132.

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.

--
Tim Slattery
Sl********@bls.gov
http://members.cox.net/slatteryt
Nov 3 '08 #10

P: n/a


Joost Diepenmaat wrote:
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.
Nov 3 '08 #11

P: n/a


Dr J R Stockton wrote:
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
Nov 3 '08 #12

P: n/a
Martin Rinehart <Ma************@gmail.comwrites:
Joost Diepenmaat wrote:
>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.
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.

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
Nov 3 '08 #13

P: n/a
In comp.lang.javascript message <qp2ug45b569qa128g04n7dhc9e5uqlimr5@4ax.
com>, Mon, 3 Nov 2008 09:34:50, Tim Slattery <Sl********@bls.gov>
posted:
>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.

--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
<URL:http://www.merlyn.demon.co.uk/TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.merlyn.demon.co.uk/clpb-faq.txt RAH Prins : c.l.p.b mFAQ;
<URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zipTimo Salmi's Turbo Pascal FAQ.
Nov 4 '08 #14

P: n/a


Dr J R Stockton wrote:
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.
Nov 4 '08 #15

P: n/a
In comp.lang.javascript message <c48de7a5-d90b-4e41-a702-131d8c387db5@b3
1g2000prb.googlegroups.com>, Mon, 3 Nov 2008 12:22:39, Martin Rinehart
<Ma************@gmail.composted:
>Dr J R Stockton wrote:
>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?
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.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/- FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "" (SonOfRFC1036)
Nov 4 '08 #16

P: n/a
In comp.lang.javascript message <87************@zeekat.nl>, Mon, 3 Nov
2008 22:00:33, Joost Diepenmaat <jo***@zeekat.nlposted:
>
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.

--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 7.
Web <URL:http://www.merlyn.demon.co.uk/- FAQish topics, acronyms, & links.
I find MiniTrue useful for viewing/searching/altering files, at a DOS prompt;
free, DOS/Win/UNIX, <URL:http://www.idiotsdelight.net/minitrue/unsupported.
Nov 4 '08 #17

This discussion thread is closed

Replies have been disabled for this discussion.