From: "Robert J. Chassell" <bob@rattlesnake.com>
Subject: Re: Source code formatting: line length limit?
Date: Sun, 26 Jan 2003 18:49:10 +0000 (UTC) [thread overview]
Message-ID: <m18crqA-000IeGC@localhost> (raw)
In-Reply-To: <84lm187ysa.fsf@lucy.is.informatik.uni-duisburg.de> (kai.grossjohann@uni-duisburg.de)
I think both of you implicitly imply that text *over* 80 columns is
bad and should be avoided.
Yes.
To illustrate my problem: I have just reformatted source code from
something like 120 columns to something below 80.
Good. There are several different reasons to prefer less than 80
columns:
* Consider someone who is interested in your code: most likely he or
she is viewing it in an 80 column width window or on a terminal
with no more than 80 columns. Not everyone uses 80
columns or less, but large numbers do.
If your reader uses 80 columns or less, either your reader
reformats the code or widens the window (assuming the latter
action is possible) Either way makes for more work for your
reader, and less likelihood that your code will be studied as
thoroughly as you would like.
* Again, consider someone who is interested in your code: one of
your readers may be different, but over the past 500 years,
printers have found that most readers tend to have a hard time
moving their eyes from one line to another unless the text
posseses the right balance of line length and between-line blank
space.
One old `rule of thumb' for determining maximum line length was
`twice the alphabet plus the punctuation'. For English readers,
this leads to line lengths in the 60s, depending on what you
consider to be punctuation. Computer displays often use a little
more inter-line spacing than printed books, and tend to do well
with a maximum line length of 70.
* Determining line length for computer code is harder than for text,
because of the advantage of conciseness. A programmer reading
your code may well have an easier time understanding a single
expression that is all on one line than the same expression split
over several lines. So that favors longer linges.
On the other hand, no one can readily ready code that goes beyound
the right hand boundary of the screen, regardless whether the line
is truncated or wrapped at the 80th character. Hence, it is a
good idea to make sure the right hand side of the line is less
than 80 characters from the left.
At the same time, code is often indented. In general, this is an
advantage; but at the same time, the reader may get lost in the
blank space to the left of the code. To counter this problem, I
often delimit expressions using GNU Emacs' parenthesis balancing
feature. But at the same time, I also make use of indenting; for
example, just yesterday, I ran `pp' on the automatically
generated, unforatted code that records a spreadsheet in Emacs
Dismal mode, so I could read it.
--
Robert J. Chassell Rattlesnake Enterprises
http://www.rattlesnake.com GnuPG Key ID: 004B4AC8
http://www.teak.cc bob@gnu.org
next prev parent reply other threads:[~2003-01-26 18:49 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-25 12:39 Source code formatting: line length limit? Kai Großjohann
2003-01-25 13:26 ` Robert J. Chassell
2003-01-26 1:21 ` Stefan Monnier
2003-01-26 13:12 ` Robert J. Chassell
2003-01-27 2:32 ` Richard Stallman
2003-01-27 14:14 ` Stefan Monnier
2003-01-26 14:48 ` Kai Großjohann
2003-01-26 18:49 ` Robert J. Chassell [this message]
2003-01-27 2:32 ` Richard Stallman
2003-01-27 13:01 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m18crqA-000IeGC@localhost \
--to=bob@rattlesnake.com \
--cc=bob@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).