Learn the Clojure style choices that most affect readability, team consistency, and tool compatibility, including naming, formatting, namespace shape, and pipeline clarity.
Style matters more in Clojure than many people first expect. The language is compact, heavily nested, and structurally regular. That means small naming or formatting choices have an outsized effect on readability.
The goal of style is not decoration. It is to make code easier to scan, easier to review, and less ambiguous under change.
In Clojure, consistency is usually more valuable than personal cleverness. If a team already follows common community conventions, keep using them unless there is a clear reason to diverge.
That generally means:
Use lowercase words separated by hyphens:
1(defn calculate-total [line-items]
2 ...)
Avoid Java-style camelCase unless the name comes directly from interop boundaries.
Predicates should normally end in ?.
1(defn active-user? [user]
2 (:active? user))
This is one of the most helpful readability conventions in the language because it tells the reader what kind of value to expect.
Names ending in ! conventionally signal an operation that may have an important effect outside pure value calculation.
1(reset-cache!)
2(save-order!)
The exclamation mark does not mean “mutates memory in place” in some strict technical sense. It is a warning that the function is effectful or operationally significant.
In idiomatic Clojure, it is often clearer to use ordinary var names for stable values than to force an all-caps constant style everywhere. Reserve loud constant naming for values that genuinely act like global constants and would otherwise be missed.
Namespace names should describe role and domain clearly.
1my-app.orders.core
2my-app.orders.validation
3my-app.http.handlers
Good namespace boundaries usually separate:
The goal is not maximum granularity. The goal is to keep related code together without turning namespaces into unstructured dumping grounds.
In modern Clojure work, code format should usually be enforced automatically. Debating personal spacing style by hand is wasted review energy.
Use a formatter such as cljfmt, and treat manual formatting preferences as secondary to consistent tool-driven output.
Indentation should reveal shape:
1(defn process-order [order]
2 (let [validated (validate-order order)
3 priced (price-order validated)]
4 (persist-order! priced)))
The point is not merely alignment. The point is that the reader can quickly see:
When several transformations happen in order, threading macros usually improve readability.
1(->> users
2 (filter :active?)
3 (map :email)
4 (remove nil?)
5 (into []))
Do not force threading macros into every expression, but use them when they clarify data flow.
Destructuring often makes function signatures and local extraction cleaner:
1(defn display-name [{:keys [first-name last-name]}]
2 (str first-name " " last-name))
This is usually clearer than repeated nested key lookups inside the function body.
The mistake is overdestructuring. If a binding form starts to look like a puzzle, the function may be trying to absorb too much structure at once.
Several layers of inline fn or #() often become harder to read than a small named helper.
Clojure code often gets worse when it imitates Java naming and class-style ceremony instead of using the language’s smaller, data-oriented forms naturally.
A namespace named core is normal. A namespace that contains parsing, HTTP, persistence, validation, metrics, and business rules all together is usually not.
If the formatter will change it anyway, do not build team habits around custom spacing tricks.
The real payoff of conventions appears in code review:
That is why style should be treated as a maintainability tool, not as an individual signature.
A codebase mixes camelCase, kebab-case, manually aligned indentation, formatter-generated indentation, and several personal preferences about when to use threading macros. None of the choices is individually catastrophic, but reviews are noisy and the code feels inconsistent.
What is the stronger fix?
The stronger fix is to adopt a small explicit style baseline, enforce formatting automatically, and make naming and pipeline conventions consistent enough that review effort shifts away from layout debates toward design and correctness.
?, and effectful ! naming conventions carry real semantic value