LISP Best Practices

Writing idiomatic LISP is less about memorizing syntax and more about internalizing a handful of conventions the community has converged on over decades: descriptive kebab-case naming, preferring built-in higher-order functions like mapcar and reduce over hand-rolled loops, keeping functions small and composable, and reaching for macros only when a function genuinely cannot achieve the same result. Following these conventions makes LISP code readable to other Lisp programmers and avoids common pitfalls like unintended variable capture or excessive nesting.

Common Lisp style favors kebab-case names like calculate-total-price over camelCase or snake_case, predicates conventionally end in a question mark such as null? in Scheme or evenp following Common Lisp's -p suffix convention, and destructive functions that mutate their argument are marked with a trailing ! in Scheme dialects like set-car!. Beyond naming, best practice keeps each function focused on a single responsibility and composes small functions together rather than writing one large monolithic function with deeply nested let and cond forms, which becomes difficult to test and reason about.

Because loops are less central to LISP than in imperative languages, best practice is to write recursive functions in tail-recursive form whenever possible so implementations that support tail-call optimization—such as Scheme, which mandates it per the language standard—can execute them in constant stack space, and to prefer built-in higher-order functions like mapcar, reduce, and remove-if over manually written recursive loops when a direct equivalent exists. Common Lisp does not guarantee tail-call optimization across all implementations, so performance-critical recursive code there often uses the loop macro or do form instead, while Scheme and Clojure programmers lean on tail recursion and recur respectively.

When writing macros with Common Lisp's defmacro, always use gensym (or the with-gensyms helper pattern) to generate unique symbol names for any local variables the macro introduces, preventing accidental variable capture where a user's code happens to use the same identifier the macro used internally. For error handling, prefer Common Lisp's condition system—handler-case, restart-case, and signal—over ad hoc return-code checking, since conditions let calling code decide how to recover (retry, use a default value, abort) rather than forcing the signaling code to guess the right response.