Fork me on GitHub
#clj-kondo
<
2019-06-07
>
borkdude09:06:54

clj-kondo v2019.06.07-alpha! 🎉 major new features: Clojure API, JSON/EDN output https://github.com/borkdude/clj-kondo/releases/tag/v2019.06.07-alpha

🎉 8
Stefan12:06:58

Ooohhhh somebody just pointed out clojure-toolbox on #clojure. Didn’t know about that one yet, really awesome! @borkdude Are you adding clj-kondo there or do you want me to do it? 😉

borkdude12:06:06

@stefan.van.den.oord I’ll give you the honors, thanks 🙂

dominicm13:06:49

I was just thinking about seeing this in a few places on a re-frame application, thought it might be worth detecting that it's unused & unnecessary: echo '(fn [[_ _]] 10)' | clj-kondo --lint -

borkdude13:06:50

@dominicm by convention, clj-kondo ignores symbols that start with _ for detecting unused args, so that would be a new type of linter: “unnecessary destructuring”?

dominicm13:06:29

The argument which is performing destructuring is completely ignored, which is why I figured it would be unused args too, but sure :)

borkdude13:06:24

if you would do [_ _ :as x] clj-kondo would already report it 😉

borkdude13:06:45

I guess you can’t assume it’s completely unused, since destructuring fails on certain things and this may be used as a feature 🙂

borkdude13:06:42

also sometimes it serves as documentation like: a seqable of at least two elements are expected here

dominicm13:06:44

You mean that someone might be doing:

(try
  (let [[_ _] :foo] true)
  (catch Exception e
    false))
?

borkdude13:06:19

yeah, or forcing at least two elements to be realized from a seq

dominicm13:06:18

could be docs, yeah. I'm a little ambivalent on that, it's either: 1) A repeating pattern (like re-frame) and therefore the docs are elsewhere 2) unique to this fn, in which case you're ignoring the argument for no reason.

dominicm13:06:25

That would be some funky code.

mynomoto14:06:12

I just linted a re-frame app and I would love what @dominicm is suggesting.

mynomoto14:06:34

No warnings from clj-kondo on the two largest projects at work. A bunch of unused code deleted, thanks for that.

borkdude14:06:42

cool, good to hear 🙂

borkdude14:06:34

I’ll think more about the [_ _] case, thanks for bringing it up

borkdude14:06:01

what if _ is in fact used somewhere, should it then also report _ that was marked as unused, but it is used? it’s like telling the linter: ignore this, but tell me when it’s not good to ignore, which doesn’t feel right to me yet…

dominicm14:06:51

My "purist" reaction is that it shouldn't be reported as unused, because it is! But I think use of _ arguments is usually a mistake.

borkdude14:06:42

the linter already doesn’t report it as unused as of now, but if you do use it, should it report the contrary (I don’t think so). but then [_ _] would also not be reported because of this.

borkdude14:06:10

_ is telling the linter: I know I’m not using this, but please don’t report anything about it

borkdude14:06:31

a convention which isn’t very clear yet among the community: how do you tell tooling to keep namespaces, although they’re not used anywhere explicitly in the code.

borkdude14:06:12

some people have brought up attaching ^:keep on a vector in which the ns name is wrapped: ^:keep [do-not.remove]

borkdude14:06:46

having it as an unwrapped to signal this could also work: (:require do-not.remove) but there might be others that are accidentally also unwrapped. also that wouldn’t work for java imports

dominicm16:06:05

I've thought that the declaration of having side effects (e.g. registering multimethods, launching rockets) should be at the (ns) level, not the the require level

borkdude16:06:25

maybe an ns can be required only for side effects in some namespaces, but for referring functions in another, so I’m not sure about that

dominicm16:06:40

if you require a namespace, you might be causing it's side effects. You don't know.

borkdude16:06:26

namespaces are only loaded once, normally

borkdude16:06:46

so the side effects should only happen once. when, you shouldn’t care about

borkdude16:06:37

we’re talking side effects of loading specs, multimethods. side effects like launching missiles is probably not a good idea as a top-level form 😉

borkdude16:06:39

this issue is not about documenting whether a namespace has side effects, but if you’re only loading it because of those

borkdude16:06:28

sometimes tools are automatically removed “unused” requires, and you want a way to prevent that

dominicm16:06:46

I understand.

tianshu16:06:39

@borkdude emmm, I mean parsing the spec definition, but not using the spec. only handle the basic predicate like string?, int?, symbol? and the regexp ops like s/*, s/+, etc. by parsing the spec, it is possible to find the arity error and type error on literals.

tianshu16:06:05

but the situation is complex, maybe it's not a good idea

borkdude17:06:08

@doglooksgood yeah, I’ve already considered that in one of the issues: https://github.com/borkdude/clj-kondo/issues/23