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.
Tag: do’s and don’ts
Clojure Don’ts: Short Fn Syntax
A mistake that shows up at least once in almost every class I teach. The Clojure reader macro #() creates an anonymous function whose body is a single expression, and that expression must be a list.
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… Continue reading Clojure Don’ts: Thread as
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… Continue reading Threading with Style
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… Continue reading Clojure Don’ts: Non-Polymorphism
How to ns
Quick link: Stuart’s ns Style Guide Everyone has their own personal quirks when it comes to syntax. No matter how hard you try to lock it down with code review, IDEs, scripts, or check-in hooks, individual differences will emerge.
How to Name Clojure Functions
This is a guide on naming Clojure functions. There are exceptions to every rule. When you’re defining something based on natural language, there are more exceptions than rules. I break these rules more often than I follow them. This guide is just a starting point for thinking about how to name things.
Clojure Don’ts: Lazy Effects
This is probably my number one Clojure Don’t. Laziness is often useful. It allows you to express “infinite” computations, and only pay for as much of the computation as you need. Laziness also allows you to express computations without specifying when they should happen. And that’s a problem when you add side-effects. By definition, a… Continue reading Clojure Don’ts: Lazy Effects
Clojure Don’ts: Redundant map
Today’s Clojure Don’t is the opposite side of the coin to the heisenparameter. If you have an operation on a single object, you don’t need to define another version just to operate on a collection of those objects.
Clojure Don’ts: Single-branch if
A short Clojure don’t for today. This one is my style preference. You have a single expression which should run if a condition is true, otherwise return nil.