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 them.

• 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 better readable.
• 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 package.

Services provided by
SourceForge