8 Coding suggestions
In order to guarantee that your program is as portable and version independent as
possible the following rules may be useful. Note that these are recommendations
only - your program may do a good job for you even if you ignore all of
- Don’t use functions from the underlying LISP which are not explicitly
part of REDUCE or standard lisp - they will probably be missing in
other support systems.
- Don’t rely on character case. Some implementations support upper
case output, others prefer lower case. As the tendency goes towards
lower case, the best policy is to use lower case characters only, except
in strings or comments.
- Use proper indentation. Take the REDUCE sources as example. If the
indentation corresponds to the block structure your programs will be
- Don’t produce lines with more than 72 characters. There are still
computers and networks around which have problem if the size of the
good old punched card is exceeded.
- Write comments. The major entry point routines of your symbolic code
should have one comment line following the procedure declaration; this
comment should be one or more complete English sentences, beginning
with an upper case character and ending with a dot.
- Try to avoid name conflicts. It is a common policy to name global
and fluid variables with a trailing asterisk and to use a common name
prefix for the procedure names.
- If you produce a large piece of software, organize it as a REDUCE
Services provided by