This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-05-06
Channels
- # announcements (3)
- # aws (23)
- # beginners (61)
- # calva (57)
- # cider (121)
- # clara (1)
- # clj-kondo (9)
- # cljs-dev (62)
- # cljsrn (3)
- # clojure (79)
- # clojure-europe (2)
- # clojure-nl (19)
- # clojure-spec (9)
- # clojure-uk (14)
- # clojurescript (92)
- # clojureverse-ops (2)
- # cursive (3)
- # data-science (2)
- # duct (1)
- # figwheel (2)
- # graphql (6)
- # jobs (1)
- # kaocha (5)
- # leiningen (11)
- # off-topic (25)
- # overtone (1)
- # pedestal (4)
- # portkey (1)
- # re-frame (1)
- # remote-jobs (2)
- # shadow-cljs (179)
- # slack-help (3)
- # specter (7)
- # testing (14)
- # tools-deps (14)
- # unrepl (12)
- # vim (2)
- # yada (3)
Is it good practice to place all specs together in a dedicated my-project.specs
namespace?
I do not know but on my project I created a separate .domain
ns with specs so that I could share them with multiple namespaces and it is nice not to have it all through the core ns. So it works for me 🙂
Thanks! I was reading a few posts and it seems there isn't really a one "correct" way of doing things
sharing specs between namespaces is the reason I'm thinking of doing it as well, and it probably makes sense for s/fdef
specs to remain next to their respective functions
I personally put specs above the code, in the same namespace. It makes sense that logically, if I want to see the "Event" spec, it would be in the event.clj namespace for example
I also have a common.clj
namespace, which contains shared functions. It also contains common specs, like ::timestamp
, which is used in many places
I’d say it can make sense for libraries at a certain scale… though even there you may just want to put them where you need them. For an application you’ll inevitably end up wanting to spread things out.
I also avoid using namespace alias ::keyword syntax and most of the specs have short 3-8 character prefixes that don't actually correspond to any of my project namespaces, wondering if that's good practice too
They don't need to correspond to actual namespaces, the main thing is I guess readability.