Subject: Re: Closing paren on separate line (was Re: macro characters) From: Erik Naggum <clerik@naggum.no> Date: 1997/12/06 Newsgroups: comp.lang.lisp Message-ID: <3090364765476608@naggum.no> * 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 tools... 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. #\Erik -- if you think this year is "97", _you_ are not "year 2000 compliant". see http://sourcery.naggum.no/emacs/ for GNU Emacs 20-related material.