There's no one solution; but there are at least a couple that tackle the problem with different trade-offs: 1. Validation with eg. malli or spec 2. Autocompletion of keywords in editor when typing 3. Find-references with lsp (so you can see you're using the exact same keyword in other places) 4. Tony Kay tried to avoid this problem to the nth-degree in Fulcro, et al. by making custom namespaced vars for each keyword. Then, you never use the keyword itself, but instead the var (which can be checked at compile time, helps with code navigation, etc.) Example namespace: https://github.com/fulcrologic/fulcro-rad/blob/develop/src/main/com/fulcrologic/rad/form_options.cljc

I just realized this was posted in #clj-kondo and not #clojure. Hope the advice is still useful, but would be interested to know if there is already something in clj-kondo or lsp that would help with this further.

Yeah, I like the way RAD options does it as well, @U05476190. Another option is https://github.com/fulcrologic/guardrails, but it creates a fairly significant load in my ETL pipeline, so it has its own tradeoffs. Maybe something like a namespaced keyword whitelist or something might be helpful? Something that defined that :a/x and :a/y are valid, but :a/z is not. At least in some circumstances it would be useful. I am curious as well if there are any considerations towards this problem in clj-kondo.

I'm actually not sold on the RAD options approach myself, primarily because I'm not convinced it's a big enough problem in my own codebases. But I did want to point it out, since it is a totally legitimate approach if you do find it an annoying problem. :)

Right now clj-kondo doesn't have the concept of "I've seen all the files" so it's hard to say whether a keyword is a mistake or not based on the frequency. But if you analyze a whole project and take a look at the keywords analysis you can deduce this yourself. Clojure-lsp however, does have the concept of "seen the whole project" and could maybe help with this somehow based on kondo's keyword analysis.

\cc @UKFSJSM38

Of course with a strict configuration like :a/foo is valid but :a/bar isn't, this would work with clj-kondo

@U05476190 spell-check helps a fair bit too, if you are using full words. A useful lint in lsp, like unused-public-vars, could be single occurrence keywords.

that's what I was thinking of

perhaps clojure-lsp could just show the frequency of each keyword, similar to vars, or would that be too expensive?

in lens-mode

I never use unused-public-var, the frequency info is sufficient for me

Single occurrence notice sounds like a happy medium. Showing a frequency next to each one might get a little noisy, but some people would probably prefer that configuration.

probably too verbose a lens for that

but a custom linter sounds a good POC/try

Maybe something along the lines of a single occurrence linter combined with what git does with typos:

$ git logg
git: 'logg' is not a git command. See 'git --help'.

The most similar command is
        log

yes, there are some kondo linters that have a similar feature like refer-all , we could do similar

Thanks everyone for giving it some thought 🙏

@UPWHQK562 In Eastwood you have a linter for that use-case (if I understood you right): https://github.com/jonase/eastwood#keyword-typos

@U8T05KBEW interesting. Thanks for the heads up on that. I do not use Eastwood, but interesting nonetheless.

Maybe create an issue with references to existing implementations / ideas.

@U04V15CAJ indeed, I should. I'll get to that a little later today. Thanks.

https://github.com/clojure-lsp/clojure-lsp/issues/923

Interesting, would love to see more real world examples of this

How many times are arguments same-named as the arguments? Not often I assume

in my experience there’s a decently high overlap of named arguments to a function and named arguments in the function declaration

Oh I feel it's pretty often, things get passed through, I'll find some examples.

In clojure-lsp we often pass analysis components or db as the last arguments.

(defn find-last-order-by-project-analysis [pred? analysis db])
(find-last-order-by-project-analysis
    #(= (:name %) (:name element))
    analysis
    db)

in the metabase codebase we have lots of common things called driver, database, card, etc. And those will be the same for invocation and most likely for the definition

Maybe that's just a sign to turn it into a {:db ...} shaped argument?

And clj-kondo already has "type annotions" for required keys

https://github.com/clj-kondo/clj-kondo/search?q=resolve-cache-dir I dunno, that's an argument that says always use named params..

yeah, there's a trade-off. can you make an issue for this and any time you find a real-world OSS example, post it there?

Yup, what are you looking for in examples? Existing bugs with this mixup or more evidence that call sites and functions use the same names?

The latter. That you can make bugs with this I believe :)

A concept PR is also welcome. I think what should happen more or less: if a symbol call argument matches a fn arg name but the position doesn't match up, it's a warning

https://github.com/clj-kondo/clj-kondo/issues/1650

I'm not sure if I'll add too many more examples, it's hard to find a function call that doesn't pass at least one var with the same name as an arg.

Well, then that's a good indication that we should give this at least a try :)

Thanks