Clojure Don’ts: Numbered Parameters

Continuing my series of Clojure do’s and don’ts — which, as always, is a mix of technical recommendations and my personal stylistic preferences — and continuing on the topic of the previous post in this series, here are some more arbitrary rules about anonymous functions.

I’m doubling down the assertion in my last post: The short anonymous function syntax #() is only for simple functions consisting of a single function or method call. Anything else deserves at least the standard fn syntax with named parameters.

I’ll go even further: Only use #() with the single parameter %. Do not use numbered parameters, as in %1, %2, %3, %&. Unless you’re playing code golf or writing Swearjure, unnamed parameters are not worth the saved characters.

I can hear the whinging already. “But what about …” No buts.

Function parameter names are one of the most important conveyors of meaning in code. In a dynamically-typed language like Clojure, they are even more important. (Static typists, this does not let you off the hook. Types alone are not enough to convey the meaning of a parameter.)

Whenever I see a cluster of characters like #(%2 %1), I have to stop for a moment and speculate about what those unnamed parameters represent. I have to make an educated guess based on context. Named parameters are always clearer.

Think of the poor, benighted Perl and Bash programmers, so bereft of named parameters they have to simulate them!

Clojure Don’ts: Thread as

A brief addendum to my last post about Clojure’s threading macros.

As I was saying …

I said you could use as-> to work around the placement of an argument that doesn’t quite fit into a larger pattern of ->. My example was:

(-> results
    :matches
    (as-> matches (filter winning-match? matches))
    (nth 3)
    :scores
    (get "total_points"))

This is not a good example, because filter is a lazy sequence function that should more properly be used with ->>. And I warned explicitly against mixing -> and ->>.

Here’s a better example.

Continue reading →

Threading with Style

No, not multi-threading. I’m talking about Clojure’s threading macros, better known as “the arrows.”

The -> (“thread-first”) and ->> (“thread-last”) macros are small but significant innovations in Clojure’s Lisp-like syntax. They support a functional style of programming with return values and make composition intuitive. They answer the two chief complaints about Lisp syntax: too many parentheses and “unnatural” ordering.

Continue reading →

Clojure Don’ts: Non-Polymorphism

Polymorphism is a powerful feature. The purpose of polymorphism is to provide a single, consistent interface to a caller. There may be multiple ways to carry out that behavior, but the caller doesn’t need to know that. When you call a polymorphic function, you remain blissfully ignorant of (and therefore decoupled from) which method will actually run.

Don’t use polymorphism where it doesn’t exist.

All too often, I see protocols or multimethods used in cases where the caller does know which method is going to be called; where it is completely, 100% unambiguous, at every call site, which method will run.

Continue reading →