Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!dimacs.rutgers.edu!aramis.rutgers.edu!paul.rutgers.edu!brushfire.rutgers.edu!gaynor
From: gaynor@brushfire.rutgers.edu (Silver)
Newsgroups: comp.lang.lisp
Subject: Re: Tradition Lisp code formatting
Message-ID: <Jun.23.08.57.04.1991.5234@brushfire.rutgers.edu>
Date: 23 Jun 91 12:57:05 GMT
References: <20899@sdcc6.ucsd.edu>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 89

whatis@gnu.ai.mit.edu writes:
> [Why is Lisp generally written so `tightly', rather than spaced out the way
>  one generally sees C et al?  I generally see Lisp written as it appears on
>  immediately below, and not as I prefer, which follows.
>
> (defun count-outlyers (list-of-elements)
>   (let ((result 0))
>     (dolist (element list-of-elements
> 		     result)
>     (when (or (> elements boiling)
> 	      (< element freezing))
>       (setf result (+ result 1))))))
>
> (defun count-outlyers (list-of-elements)
>     (let
> 	(
> 	    (result 0)
> 	)
> 	(dolist
> 	    (element list-of-elements result)
> 	    (when
> 		(or
> 		    (> element boiling)
> 		    (< element freezing)
> 		)
> 	        (setf result (+ result 1))
> 	    )
> 	)
>     )
> )
> ]

One reason may be the common misconception that whitespace is `cheap' or
`free'.  Too much whitespace can be as detrimental to readability as too
little.  This is especially true in the vertical direction, noting that
characters are generally taller than they are wide (for example, standard glass
terminals are ~24x80).

Note that the blocking structures of the two excerpts of code you provide are
not so different.  From your code samples, you claim preference for the style
on the left; standard lisp formatting is on the right.

    expression                          expression subexpression
        subexpression                              subexpression
        subexpression                              subexpression
        subexpression                              ...
        ...

The indentation format on the right is referred to as hanging indents, ie,
hanging the indentation for an expression off of the indent point for the
previous one, wherever it may be.  This style trades some vertical space for
horizontal, taking advantage of the less-used rightmost screen acreage.

This style is the general case.  But sometimes the right edge of the screen
creeps up a little too quickly, so skip to some small extra indentation on the
next line.  For example, the form on the left might have to be abandoned for
the one on the right, below.  (The right edge is indicated by pipes.)

    ...                     |           ...                     |
    (long-function-name 'bla|h          (long-function-name     |
                        'ble|tch          'blah                 |
                        'ble|chh)         'bletch               |
    ...                     |             'blechh)              |
                                        ...                     |

Also, there are times when the semantic differences of some of the leading
arguments should be emphasized to make them distinct from the remaining ones.
This is typical of special forms which control the flow of evaluation.  This
emphasis is usually shown by indenting them farther, or hanging their indents
and not hanging the indents of the remaining elements.  Hard to explain, easy
to show:

  (let ((variable value)                (let
        ...)                                ((variable value)
    bodyform                                 ...)
    ...)                                  bodyform
                                          ...)

The last item to address is the handling of closing parens across expressions
that span multiple lines.  You claim preference for putting them on their own
line indented at the same level as the matching open paren.  In your preferred
style, you dedicate 10 lines to single closing parens, making it over 2.4 times
as long as the other.  That's a LOT! of whitespace.  I can think of a few
reasons why this would be done.  The first is because it facilitates visual
matching.  But with smarter editors that blink match and move over balanced
expressions, that's no win.  The second is because it easier to move blocks of
code around.  That point I'll concede.

Regards, [Ag]