This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-09-21
Channels
- # announcements (3)
- # architecture (5)
- # babashka (19)
- # beginners (145)
- # calva (1)
- # chlorine-clover (18)
- # cider (10)
- # clj-kondo (5)
- # cljsrn (3)
- # clojure (56)
- # clojure-berlin (19)
- # clojure-czech (2)
- # clojure-europe (32)
- # clojure-finland (2)
- # clojure-nl (3)
- # clojure-portugal (2)
- # clojure-spec (8)
- # clojure-uk (48)
- # clojurescript (48)
- # conjure (50)
- # cryogen (1)
- # cursive (28)
- # datomic (54)
- # depstar (12)
- # emacs (1)
- # events (8)
- # figwheel-main (6)
- # fulcro (4)
- # helix (4)
- # java (2)
- # jobs (2)
- # leiningen (1)
- # off-topic (29)
- # parinfer (4)
- # pathom (6)
- # portkey (3)
- # reagent (1)
- # remote-jobs (3)
- # reveal (16)
- # shadow-cljs (42)
- # sql (20)
- # tools-deps (11)
- # vim (4)
- # vrac (2)
Guten Morgen!
a small question of style for you...
when I see the update-last
from @otfrom I can grok the if and the else cos it's a snappy bit of code
(defn update-last [v f & args]
(if (seq v)
(conj
(pop v)
(apply f (peek v) args))
v))
but I am always a little concerned with Clojure that too many forms between an if and the else can allow the else to get a bit lost and can (has been for me) the cause of silly bugs
so I think this one here is definitely within bounds ... so do you feel the same and if so when would you break out the cond
or something like this
(defn update-last [v f & args]
(cond
(seq v) (conj
(pop v)
(apply f (peek v) args))
:else v))
like I say, over the top for this case but for me, 2 or three more lines of the true side of the if
and I would break out the cond or do an if-not
(defn update-last [v f & args]
(if-not (seq v)
v
(conj
(pop v)
(apply f (peek v) args))))
thoughts?Maybe
(if (empty? v)....
Agree with the easy flow at the beggining, and with using cond when things become hairy.
for me if either leg of the if became too long I'd prefer to factor it into another funciton and keep the if short
I usually write out the function all in one and then factor out the legs. Testing in a rich comment block as I go
I, too, love multimethods but they get in my way so easily with code reload, or when abused as a “plugin system”.
Maybe it’s just bad coding habits on my side. I like cond
and potentially calling individually named functions which help understanding what’s going on
@ordnungswidrig yeah, I find that too. I usually do them b/c I know things are going to have complicated bodies or refactring a cond
individually named functions are good. multimethods means that I can worry slightly less about names