This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-07-20
Channels
- # announcements (7)
- # babashka (16)
- # beginners (58)
- # boot (12)
- # calva (3)
- # cider (11)
- # clj-kondo (9)
- # cljs-dev (8)
- # clojure (82)
- # clojure-europe (9)
- # clojure-italy (11)
- # clojure-losangeles (1)
- # clojure-nl (8)
- # clojure-uk (8)
- # clojurescript (5)
- # css (2)
- # cursive (5)
- # datomic (20)
- # docker (2)
- # emacs (4)
- # figwheel-main (16)
- # fulcro (53)
- # graalvm (17)
- # jackdaw (2)
- # jobs (4)
- # kaocha (6)
- # lambdaisland (2)
- # luminus (2)
- # meander (1)
- # off-topic (146)
- # re-frame (4)
- # releases (1)
- # rum (12)
- # sci (71)
- # shadow-cljs (26)
- # test-check (22)
- # vim (1)
- # xtdb (9)
This is more a question about opinions on style:
clj-kondo
warns against unused function parameters. I use Cursive, which already does that. So now, I have both a greyed out symbol (Cursive) as well as a squiggly line underneath the symbol clj-kondo
. They really want this to be visible!
However, some “functions” are e.g. defmethod
s, implementations of a defmulti
. Having the names of the parameters repeated in each defmethod
makes the code easier to scan as the signature makes those particular defmethod
s very visible, and Cursive signals to the person reading the function that parameter x
isn’t used anyway, so they can ignore it. Therefore, could it not be argued that changing x
to _
detracts from the readability of the code (at least in Cursive)?
Similarly, a defmulti
may take arguments x
and y
, but only use x
in the default implementation. If x
and y
are well-named to give some context to the function, don’t we lose something by renaming y
to _
, like clj-kondo
and Cursive wants us to? Implementers of defmethod
s for the defmulti
will have less context to go on.
This could be argued for any function, really, defmulti
and defmethod
s just seem particularly vulnerable to loss of context, imo.
@reefersleep You can still use names like _x
and _y
though?
Funny thing, though; doing this means that the symbols are no longer grayed out, which makes it harder to scan for me, initially, at least. (a signature of [_ _]
is quick to scan, [_person _vehicle]
is less so)
And while the convention might show that _
-prefixed symbols are unused, they could _actually_ be used further down, now that they are shown in the same manner as other symbols (not grayed out). The same goes for _
, I guess, but it seems less risky.
So from my perspective, maybe _x
should be saved for special cases, and I’ll go with _
for the majority of cases.
I’m reasonably happy 😄