Clojurians Log v2

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?

Well, that solves my problem. Didn’t know about that! Cheers @borkdude!

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.

As long as you are happy 🙂

I’m reasonably happy 😄