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.
Cricket analogy: Idiomatic LISP conventions are like a batter grooving a textbook forward defensive rather than improvising a wild slog every ball; the shot works, but coaches recognize and trust the technically sound version immediately.
Naming, Structure, and Function Design
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.
Cricket analogy: Naming conventions like the -p suffix for predicates are like a scorecard consistently using 'c Smith b Jones' notation for every dismissal, so any reader instantly knows a catch occurred without extra explanation.
;; Prefer small composable functions over one large nested function
(defun evenp* (n) (zerop (mod n 2)))
(defun sum-of-evens (numbers)
(reduce #'+ (remove-if-not #'evenp* numbers)))
(sum-of-evens '(1 2 3 4 5 6)) ;; => 12
;; Destructive mutation is named with a trailing bang in Scheme style
(defun set-first! (lst value)
(setf (car lst) value)
lst)Recursion, Tail Calls, and Higher-Order Functions
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.
Cricket analogy: Tail-call optimization is like a bowler running through their delivery stride so smoothly that no extra energy is wasted between overs, letting them bowl indefinitely without tiring, versus a jerky action that accumulates fatigue with every ball.
In Clojure, which runs on the JVM and cannot rely on true tail-call elimination, use the explicit recur special form for self-recursion in tail position; the compiler verifies at compile time that recur is actually in tail position, giving you constant stack space safely.
Macro Hygiene and Error Handling
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.
Cricket analogy: Using gensym to avoid variable capture is like an umpire wearing a distinctly numbered coat so nobody confuses them with a player of the same surname already on the field, avoiding any mix-up in decisions.
A macro written with defmacro that binds a temporary variable using a plain symbol like temp can silently break if the calling code also has a variable named temp in scope—this is exactly the variable-capture bug that gensym-generated unique names prevent. Always test macros with argument expressions that reuse common variable names before shipping.
- Use kebab-case naming,
-por?suffixes for predicates, and!suffixes for destructive mutating functions. - Keep functions small and composable; avoid deeply nested
let/condmonoliths. - Prefer higher-order functions like
mapcarandreduceover hand-written recursive loops when a built-in equivalent exists. - Write tail-recursive functions where possible; rely on Scheme's guaranteed tail-call optimization or Clojure's explicit
recur, since Common Lisp does not guarantee TCO across implementations. - Always use
gensymorwith-gensymsinside macros to avoid accidental variable capture. - Prefer Common Lisp's condition system (
handler-case,restart-case) over ad hoc error codes so callers can decide how to recover. - Only reach for a macro when a function genuinely cannot achieve the same result, since macros are harder to debug and reason about.
Practice what you learned
1. What naming convention does idiomatic Common Lisp use for predicate functions?
2. Why is `gensym` used inside `defmacro` definitions?
3. Which LISP dialect guarantees tail-call optimization as part of its language standard?
4. How does Clojure ensure a self-recursive call is safely optimized on the JVM?
5. What advantage does Common Lisp's condition system offer over simple error-code returns?
Was this page helpful?
You May Also Like
LISP vs Modern Languages
A comparison of LISP's core design choices—homoiconicity, macros, and minimal syntax—against mainstream languages like Python, JavaScript, and Java.
LISP Quick Reference
A condensed cheat sheet of core LISP syntax, data structures, and special forms for Common Lisp, covering the operations used daily.
Building a Simple Calculator in LISP
A hands-on walkthrough of building a working arithmetic expression calculator in Common Lisp, from tokenizing input to evaluating nested expressions.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics