Don't override built-ins
Sep 29 2016
Recently, I was working on a Clojure project, and I came across a naming decision. The name I wanted,
resolve, was taken by
On the one hand, someone might encounter this function in the code and expect the
clojure.core/resolve. One the other hand, I didn’t want to have to sacrifice the right name just because of the language. Additionally, I named the function with the expectation that it would be called through it’s namespace,
file/resolve, which differentiates it from
clojure.core/resolve, except for inside the
file namespace, or if a client chose to refer the function into another namespace.
I chose to use the name.
A few weeks later, I found myself on the other end of that same decision someone else made. I was reading through a namespace, and perplexed by a particular call to
update. After spinning my wheels for a bit, I finally realized that
update was refering to a locally defined function, not
Two things contributed to my confusion.
clojure.core/updatefairly often, thus I have expectations about its behavior.
My editor colorscheme highlights core functions differently than other functions. So a local version of
updateis colored the same way as
clojure.core/update. Naturally, I have become dependent on the way my editor highlights the code.
Now that I have been bitten by this, I expect I will be less likely to use a name already used in
clojure.core, or a built-in in any language. Perhaps the prevalence of the function will play into the decision. I use
clojure.core/update all the time. I have expectations about behavior when I encounter that function. I use
clojure.core/resolve much less frequently. In fact, I have never used it!