NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/lang/lisp/2320

Internet Message Format | 1992-08-27 | 3.5 KB

Path: sparky!uunet!mcsun!news.funet.fi!hydra!klaava!cc.helsinki.fi!pirinen
From: [e-mail]
Newsgroups: comp.lang.lisp
Subject: Re: style-guide
Keywords: style
Message-ID: <[e-mail]>
Date: 27 Aug 92 22:49:13 GMT
References: <[e-mail]>
Sender: [e-mail] (Uutis Ankka)
Organization: University of Helsinki
Lines: 63

An interesting subject and a good starting point, I guess I must
comment.  (I wrote something yesterday, but I think the machine managed
to lose it while sending, so here we go again:)

I think programming style is an aspect of the central skill of a
programmer.  That skill is communication.  Some people like to repeat
Dijkstra's dictum: Someone who doesn't have a good command of her native
tongue cannot be a good programmer (excuse me for not quoting verbatim,
but I am at the moment separated from my reference library).  Things are
not quite that simple, but writing a professional program is an act of
communication, and cannot be mastered without knowledge of the art of
technical writing.

You rightly emphasise using 'the most specific construct'.  This, to my
mind, is the central principle of technical communication, although 'the
most appropriate construct' might be a better way of putting it.  Strunk
& White put it in their usual admirably terse and concrete style: 'the
right word in the right place' (I also don't have my style guides handy,
but I think I remember that right).

Data abstraction is A GOOD THING.  Therefore everything that can be
represented as a data structure should be have an accessor and a setf
method, and possibly a creator, mapping functions, etc.

There should probably be a whole chapter on the pitfalls of complex setf
methods.  I might write that chapter when I return my erstwhile
employer, Harlequin, and regain access to some good examples of them.

The VALUES form is not a good indicator of how many values are being
returned, especially when the values are just being passed through:
(VALUES (FLOOR X Y)).  Why not just use comments? Commenting the
arguments and return values of all functions external to a module is a
good principle.

SETF (VALUES ...) is a handy idiom, when you don't want to create a data
structure for a set of values that form a conceptual unit.

CATCH and THROW have their place, when you truly want dynamic scope and
a restart is not appropriate.  They could, however, often be replaced by
using RETURN-FROM encapsulated in a closure, a technique a CL programmer
should understand anyhow.

Macros are a major reason why Lisp is such a great language to write
programs in.  They are a great aid to clarity, if used adroitly.  Macro
writing is the touchstone of a Lisp programmer's skill.  Therefore do
beware, but do dare!

It is useful to develop a toolkit for writing complex macros.  Using
GENSYM to prevent the capture of lexical names (note: block, tag,
function, and macro names as well) is just the beginning.  (MAKE-SYMBOL
original-name) is better than GENSYM when you have to debug the
expansion.  DESTRUCTURING-BIND is handy, the only problem is that many
implementations don't do much error checking.  One that does, like
Harlequin's, is a great aid to syntax checking.

I didn't quite get what you mean by asymmetric REDUCE?

FORMAT ~A is an invitation to false assumptions because it hides
information.  FORMAT also deserves a chapter of its own, even though
'FORMAT style' sounds like an oxymoron.
__
Pekka P. Pirinen         [e-mail]
University of Helsinki, a once and future harlequin