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 ·············@helsinki.fi
University of Helsinki, a once and future harlequin
From: Jeff Dalton
Subject: Re: style-guide
Date:
Message-ID: <7389@skye.ed.ac.uk>
In article <··················@cc.helsinki.fi> ·······@cc.helsinki.fi writes:
>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.
That's not a better way of putting it, it's saying something
different. Picking the most appropriate construct does not
necessarily require picking the most specific one.
>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).
That's fine unless it's taken to mean there's always a single right
word.
>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.
I tend to think the answer to the problems of complex SETF methods
is not to use them (though I have used them once or twice), so I'd
be interested in seeing some good examples.
>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.
It might be useful to have some guidance on when to make this
replacement. Anyway
>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!
Just so.
-- jd
In article <··················@cc.helsinki.fi> ·······@cc.helsinki.fi writes:
[good comments, until...]
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.
Values aren't just being passed through here. The values form is a
normal function call, not some multiple-value-call construct. One
value, the first value returned by FLOOR, will be returned by VALUES.
See pg 181 of cltl2, which uses (values (floor ...)) as an example of
explicitly returning one value.
--
Tim Moore ·····@cs.utah.edu {bellcore,hplabs}!utah-cs!moore
"Wind in my hair - Shifting and drifting - Mechanical music - Adrenaline surge"
- Rush