Lisp Style Rules

Riastradh’s Lisp Style Rules are a wholly holistic and unscientific take on Lisp style rules. They have helped me not only to get a better sense of how Lisp people do things, but also why. There is other stuff like this around the Internet, but this is the only I’ve found that I enjoyed reading.
While there are a lot of good rules in the guide, not all of them were new to me, so I only took notes on the ones that I found interesting for one reason or another.

The rules in the guide are implemented in Emacs Lisp modes, along with the Paredit utility.
My notes follow.

  • Call them brackets, not parentheses
  • /round brackets/ -> ( and )
  • /square brackets/ -> [ and ]
  • /curly brackets/ -> { and }
  • /angle brackets/ -> < and >
  • Since they are balanced, refer to them as either the opening or closing bracket

Line Separation

  • In long, quoted lists, insert a new line before the opening bracket and also the closing bracket; it makes the list easier to read and maintain.

Indentation and Alignment

  • “If the first subform is a non-special name, however, then if the second subform is on the same line, align the starting column of all following subforms with that of the second subform. If the second subform is on the following line, align its starting column with that of the first subform, and do the same for all remaining subforms.”
  • You can force [your Lisp editor] to format lists of literal data correctly by inserting a newline after the first item in the list; forcing the remaining data to line up with that item (per the behavior described in the previous entry).


  • “Symbolic names are written with English words separated by hyphens. Scheme and Common Lisp both fold the case of names in programs; consequently, camel case is frowned upon, and not merely because it is ugly. Underscores are unacceptable separators except for names that were derived directly from a foreign language without translation.”

Scheme Specific

  • Procedure whose sole purpose in life is to answer a yes or no question, yielding a boolean, are called ‘predicates’, and end with a question mark.
  • Procedures whose sole purpose in life are to modify an object are called ‘destructive’, and end with an exclamation point.
  • Append an asterisk onto procedures names that are a variation on the original. Writing such a function, here, generally seems dubious.
  • “Prefix `WITH-‘ to any procedure that establishes dynamic state and calls a nullary procedure, which should be the last (required) argument. The dynamic state should be established for the extent of the nullary procedure, and should be returned to its original state after that procedure returns.”
  • Prefix `CALL-WITH-‘ to any procedure that calls a procedure, which should be its last argument, with some arguments, and is either somehow dependent upon the dynamic state or continuation of the program, or will perform some action to clean up data after the procedure argument returns.


  • Headings have four semicolons
  • Top-level comments have 3
  • Comments on code have 2
  • Margin comments have one
  • Use Emacs’s Outline Mode to take advantage of this approach


  • Use meaningful names; not abbreviations. No cheating.
  • Don’t use single-letter variable names; name to convey how the procedure works.

Round and Square Brackets

  • Only use round brackets
  • This is the only thing portable in R5RS
  • While square brackets are allowed in R6RS; eventually you end up discovering that you do not use brackets to read the code, anyway.

ADDENDUM: 09/07/10
Here is a link to a mirrored copy:

One thought on “Lisp Style Rules”

  1. I discovered Emacs in ’97 when I was doing C++ dempolevent for BellSouth (the Sun dempolevent tools had great integration with either vi, Emacs or XEmacs editors). I’d been a hardcore vi user since 1990 (still am), but I could adapt Emacs (actually, for some reason I opted for XEmacs at the time can’t remember why maybe it had better fonts) better for the job at hand. Syntax highlighting check (vi never had this it only arrived with vim), split buffers (top for the .h, bottom for the .cpp) check, tab completion for finding files check, nice macro record/playback features check, nice search/replace check,control behavior of tab key check, auto replace tabs with 4 spaces check. So, after a while you can imagine I crafted a pretty customized/personal .emacs file. I even continued to use emacs for a while after switching to Java in 2000 (it wasn’t until Eclipse 2.0 before I switched to an IDE and left Emacs behind).Then I moved on, and for some reason the .emacs file got left behind. Shame really I haven’t really used Emacs since it’s not the same without my .emacs file and I don’t have the time or inclination to re-create it.

Leave a Reply

Your email address will not be published. Required fields are marked *