From sad experience, I've trained myself to avoid :db/ident's where if you strip off the namespace, you're left with a name that is the same as a clojure.core function. For example, say you have some idents in your schema such as :client/name, :client/key, and :client/unique and you have a function that destructures a client:
(defn client-thing [{:client/keys [key name unique]}]
[key name unique])
Then maybe things change and your function doesn't need to access all of the fields of client. If you remove unique from the destructure, the analyzer/linter will warn you, and the thing won't compile.
(defn client-thing [{:client/keys [key name #_unique]}]
[key name unique]) ;; error squiggles under unresolved symbol 'unique'
But if you drop either key or name (forgetting to change the body), there will be no warning, no squiggles, and even if it compiles, your program will clearly be wrong.
Anyone else faced this? How do you handle it?title is also a useful alternative to name sometimes
If I have to work with something that has a :client/key or :client/name, I tend to not destructure and use the whole keyword to access the fields. If I need to destructure I'd use {client-name :client/name client-key :client/key}. I also have been bitten a few times by strange errors so now I prefer to work around shadowing, when possible
oh this is handy too https://guide.clojure.style/#idiomatic-names
The only one that really annoys me is name, so i just use that and call clojure.core/name when I want the function. It's really hard to not call a name of a thing name as a label.
I have been bitten by this. I usually do label or display-name , kind instead of type, ...
I never shadow symbols
{k :client/keys, n :client/name, u :client/unique}
I've been bitten too many times. I just avoid it.
ima guess that this is a thing clj-kondo can tell you about tho
yeah it'll warn you. (but again, I just never do it. it's easy to avoid.)
☝️ yeah if I already have a thing named e.g. :client/name I do the same
yeah that's my take. if you're destructuring, you already have a great name—esp if it's a namespaced key. I rely on that and use very short symbols for locals.
My current approach is a verbose/redundant local name. My schemas are all :client/client-name or :client/client-key. Then when I destructure I end up with client-name and avoid shadowing.
Some people don't mind shadowing but it drives me mad. Not worth the potential of stepping on a rake.
A few years ago I noticed that some fellow shadow-haters keep a list of alternate terms: nom, kind, klass