unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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

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