is there a way to stop these warnings?
How do people safely move functions from one namespace to another? I notice that I’m making a big mess of my code right now, delaying moving functions that really should live somewhere else.
Some of these functions don’t have tests (or have tests for any of their callers), so I fear (maybe irrationally) that I’m not getting some sort of feedback that I’ve broken something, due to missing changing a caller.
How do you all safely do these operations? (I feel like even if I had, say, kaocha watch
running all the time like I love doing, it’d still miss some of these types of errors — in other words, it wouldn’t catch it at compile time. Is that incorrect?)
If these errors can’t be typically caught at compilation time during test runs, would something like clj-kondo
catch these errors? (I’ve been meaning to try clj-kondo
for a year, but this use case would push it to the very top of my list!)
THANK YOU!
I second exactly what @cfleming said. Copy over the function and change the usages of the old one (pinning find usages to bottom pane), one by one, and then just delete the old.
So, first off, the compiler will tell you if a symbol cannot be resolved. So just compiling all namespaces will tell you if a var is missing.
Cursive also highlights it like so
But to the broader question: I usually keep everything in a single, massive namespace to start.
Once things solidify and the file becomes burdensome to navigate, then you can start migrating out chunks. At that point, it will be much more clear what goes where.
Pro tip: Section headers in comments go a long way toward making navigation easier.
e.g.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Metrics ;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Yes, clj-kondo will probably catch this
That’s so fantastic, @borkdude! Excited to try this out — and congrats and kudos on all the amazing tools you’re creating! 🎉🎉🎉
Note that clj-kondo might also have false positives regarding unresolved-vars if you define them using custom macros, but you can usually solve this using a config. Hop by in #clj-kondo if you need help with this. See https://github.com/clj-kondo/clj-kondo/blob/master/doc/editor-integration.md how to set it up with IntelliJ, but you can also just run it from the command line.
If you choose to set up an editor with clojure-lsp (e.g. Calva) then you will also get clj-kondo for free and navigation / renaming, etc also works
That’s freaking amazing. Thank you — I’ll be surely posting my experiences in #clj-kondo soon!
@genekim I usually do this by doing a Find Usages on the function I’m going to move and pinning the results in the Find toolwindow. Then I move the function and fix the usages by stepping through the find results. Cursive will also mark usages which no longer resolve as @potetm pointed out. I’m planning to have a single refactoring option for this but there’s an intermediate step which needs to happen first.
Oh, that’s so freaking smart, @cfleming — I will be sure to use that technique immediately as well. Thank you!!! So helpful!!!
I actually use this technique a lot for other sorts of refactorings too - if I add or remove a parameter from a function, for example. Often I’ll find something else that needs fixing and I’ll do another find usages and open it in a new tab in the Find toolwindow, so I build up a list of to-do lists and then just work through them all.
I'm glad we're getting this in emacs now too with clojure-lsp. Finally catching up with Cursive I guess :)
Yeah, I actually had to use that refactoring method the other day.
Goes pretty fast if you learn the key bindings 🙂
Okay, I’m definitely biting on that one, @potetm — which bindings/commands are you referring to? Seems incredibly high potential!
“Next/Previous Occurrence”