Using `let` for Local Bindings

let is the normal way to introduce local names in Clojure.

If def and defn create namespace-level vars, let handles the opposite job: temporary names that exist only inside one expression.

That makes let one of the most important tools for Java developers who are used to local variables inside methods.

What let Actually Gives You

At a glance:

This is why let shows up everywhere in idiomatic Clojure. It is not boilerplate. It is the basic local-structure tool.

The Simple Case

1(defn invoice-total [subtotal tax-rate]
2  (let [tax (* subtotal tax-rate)]
3    (+ subtotal tax)))

tax is visible only inside the body of that let.

That matters because it keeps the function self-contained. Nothing new appears in the namespace, and nothing outside the let can depend on tax.

Bindings Are Sequential

One detail from the language semantics matters a lot: each binding can see the earlier ones.

1(let [subtotal 100M
2      tax      (* subtotal 0.13M)
3      total    (+ subtotal tax)]
4  total)

This reads top to bottom. tax can use subtotal, and total can use both.

That is one reason let works so well for multi-step calculations. You can write the logic in the order a reader would naturally explain it.

Use let To Keep Helper Values Local

A common beginner mistake is to promote temporary values to top-level definitions too early.

This is usually wrong:

1(def discount-rate 0.10M)
2
3(defn discounted-total [subtotal]
4  (* subtotal (- 1 discount-rate)))

If discount-rate is truly application configuration, a top-level var may be fine. But if it exists only to explain one small calculation, keep it local:

1(defn discounted-total [subtotal]
2  (let [discount-rate 0.10M]
3    (* subtotal (- 1 discount-rate))))

That keeps the namespace focused on real API entries instead of small one-off helper constants.

Destructuring Is Where let Gets Powerful

let becomes much more useful once you stop treating it as just “local variables.”

With destructuring, you can bind directly from structured data:

1(let [{:order/keys [id status total]} order]
2  (str "Order " id " is " status " for " total))

Or from a vector:

1(let [[x y] [10 20]]
2  (+ x y))

This is one of the biggest quality-of-life improvements over Java boilerplate. Instead of repeated getter calls or index lookups, the shape of the data appears directly in the binding form.

Use let To Clarify, Not To Stage Every Single Step

let is helpful when it improves readability. It is not mandatory for every expression.

These are both reasonable:

1(inc (* qty unit-price))

1(let [line-total (* qty unit-price)]
2  (inc line-total))

The right choice depends on whether the intermediate value has meaning worth naming.

That is the main rule: name a value when the name teaches something useful.

Prefer let Over Nested Function Calls When The Logic Has Shape

Java developers sometimes try to preserve “one expression” style even when it becomes hard to read.

If the calculation has clear stages, let is usually kinder to the next reader:

1(defn ready-to-ship? [order]
2  (let [paid?        (= :paid (:order/status order))
3        has-address? (some? (:shipping/address order))
4        has-items?   (seq (:order/items order))]
5    (and paid? has-address? has-items?)))

That is easier to review than a dense boolean expression with repeated lookups.

Knowledge Check