Subject: Re: Closing paren on separate line (was Re: macro characters)
From: Erik Naggum <>
Date: 1997/12/06
Newsgroups: comp.lang.lisp
Message-ID: <>

* Chuck Fry
| The style you recommend is fine when you know your code is mostly stable
| as it stands.  For code under active development by multiple programmers,
| I prefer leaving the trailing ) of PROGN-like constructs and some
| multi-line function calls on a separate line.
| Why?  Because sometimes during development there's a need to comment out
| a form in one of these contexts.  If the trailing ) of the containing
| form is on the same line, you then have to add another trailing paren,
| and Emacs complains.

if you use Emacs, skipping the whole form to insert a newline is a piece of
cake.  also, if you have `comment-region' bound to a key (I use C-;), you
can mark the whole sexp with `mark-sexp', normally bound to M-C-@ and
M-C-SPC, comment out the region, exchange point and mark, insert a newline,
and that's about it.  M-C-@ C-2 C-; C-x C-x C-j

on the other hand, if you know you're going to comment out a region, you're
much better off with the nesting comment syntax: #| ... |#.  since this
ends with the |#, not with the end of the line, M-C-@ #| C-x C-x |# will
have commented out a sexp.  I much prefer this comment style wherever it is
available, and implemented it for Emacs Lisp, too.  (it never got into the
distribution, however.)

| Also remember that there's no accounting for taste.

it's also curious to watch people rationalize their styles by blaming their

that said, I find excessive whitespace around parentheses in any language
_very_ disturbing.  in particular, whitespace _after_ an open paren or
bracket and _before_ a close paren or bracket bothers me enough to (want
to) fix it before I proceed to (try to) read the code.  indeed, whitespace
can increase the importance of the trivial and unimportant just like lack
of whitespace can hide and obscure the important.

whitespace is a profoundly powerful tool when communicating with the human
reader of source code -- so I tend to think that people who don't
understand the importance of whitespace cannot have understood much else,
either.  this negative view is of course only exacerbated by the huge heaps
of really bad code one comes across with whitespace abuse in it, too.

if you think this year is "97", _you_ are not "year 2000 compliant".

see for GNU Emacs 20-related material.