Hi. Do you have guidelines, or rules of thumb for naming specs in the following two situations 1. do you rather choose a name that describes the role that the data plays in the enclosing structure (say, ::confirmation-url), or a name that describes the intrinsic kind of data that key holds (say, ::url). I tend towards the former, because I think the more descriptive keys read better, but I'm wondering if by doing so I'm not inadvertantly creating private DSL (fragmenting keys when I could have one large overarching key instead and maximise the number of functions that can operate on the data) 2. when do you use symbols rather than keywords to name specs? I tend to use symbols as a kind of zero-arg spec-op, specs that I think of as building blocks, reserving keywords for specs that I would expect to actually appear in maps. Is that a personal quirk of mine?

1. I would say both. Name the generic thing, then have the specific one refer to the generic one.

2. You should never name specs with symbols (those are reserved for function specs)

Lots of places in spec make that assumption and you are likely to be burned by using symbols.

Thank you! That answer was fast and very clear cut, I appreciate that 🙂

By “symbols” do you mean vars with def or literally (s/def ‘symbol ...)?

I go back and forth on whether I should register specs or just def the spec object. I’m on a “don’t register” swing now

@favila (s/def ::keyword ...) vs (s/def 'symbol ...) -- the code assumes that only function specs use symbols (s/fdef 'foo ...)

I know this, I am asking OP what he meant

Both Alex and I made the same assumption and the OP didn't correct Alex so... ¯\(ツ)/¯

You were correct about what I meant, @seancorfield. Thanks for suggesting using a plain def when there's no need to s/def a keyword, @favila.