How to refactor Elixir with confidence?

Questions / Help
1

Is there some tool that can help us refactoring our code base so we don’t leave undefined functions somewhere in the depths of our code?
Or if anyone has some tips on how to optimize it. Since we don’t have types and a compiler to check on those things, and I’m kind lost on how to approach it.

Thanks in advance!

1 Like
2

Maybe dialyzer would help with

so we don’t leave undefined functions somewhere in the depths of our code

It certainly helps me with this.

Also tests.

3

Mix xref may help a bit too

1 Like
4

What do you mean? There is most certainly a compiler, and it warns about undefined functions…

1 Like
5

@joaoevangelista
I would vote for:

  1. use ex_unit tests for testing your code. ( then you can refactor easy)
  2. add coverage tool: https://github.com/parroty/excoveralls for spotting uncovered zones.
    ( to be safe: codecoverage run code but it’s up to human to have the right tests :smiley: meaning you can run code without really testing it sometimes. All coverage tools need also to be reviewed by humans, but they are incredibly awesome )
  3. use Typespecs and dialyzer for automating ( see book ref at the end for this)
  4. for doc coverage : https://github.com/rrrene/inch_ex
  5. from my personal pov and experience:
    when do unit_test focus on public interface tests. Don’t test private function to much because this will change . The public function should not change much, so you need to test this good, and if you test public you test private function that compose your public function/module.
    this is needed when you want to spare cost maintenance of tests.

If you do this i think you can refractor with confidence

I would also suggest you the great book https://pragprog.com/book/tvmelixir/adopting-elixir , it adress your question and more . ( i’m currently reading and i really like it :love_letter:)

3 Likes
6

I can not stress the usefulness of mix xref enough. I use it alout to find unused functions and modules. mix xref callers MODULE_OR_FUNCTION provides very useful information about which file and from which line is calling the given module or function.

Apart from the mandatory tests, I would also recommend using credo to get insights about possible improvements, code duplication, function nesting, etc.

If you have a CI setup, I would advice to use mix compile --warnings-as-errors to cause any builds with comilation errors to fail and to include mix format --check-formatted to ensure that the source is formatted properly.
We can agree or disagree with Elixir default formatting settings, but having a common formatting accross all the source files makes them much more easier to work with.

5 Likes
7

That’s alot!
mix xref wil be the most powerful tool for doing that, I keep forgetting about it, dialyzer would help too, while coding Thanks Elixir-LS!. I think the problem with me is that I will need to change the way I iterate, even doing tests and using CI, I relied too much on IDEs to do that kind of stuff, just a shortcut and done! renamed.
credo will support most of inspections I’m used of.
Combining xref with a defined public API can be the way to go, also a more “flowable” dependencies between modules. Maybe it been different than other languages leads us to think about what we are coding more than simply throw code into an editor.

8

I was trying to figure out how to use mix xref today to find all unused (dead code) functions after a recent major refactoring. I know many stale functions in my project no longer have callers… is there an automated way to find them? I found GitHub - joshuaclayton/unused: Deprecated; see https://github.com/unused-code/unused which looks promising also but couldn’t get it to install from homebrew.

9

Yeah the compiler will definitely warn you about a function that doesn’t exist if you are trying to call it, or an unused function.

However, besides running Dialyxir on my codebase, I find that testing is the best way to approach this. Unit test all of your functions. Write good integration tests as well. That way, if you change anything, your tests will tell you what’s wrong, or at least what has changed so that you can fix it. Testing is important to make sure your code works as you intended but really, in my experience, a well-written test suite is extremely good at telling you what to fix after a refactoring.

My test suite gives me confidence that after I refactor something I know exactly what I missed.

1 Like
10

As far as I know the compiler will only emit warnings about private unused functions. Public unused functions will not be notified in any way.

I’ve been playing myself with the idea of building an elixir command that used mix xref underneath and report about unused functions. Turns out that the thing is really complicated because functions can be called dynamically using apply, Task, etc.

For the moment I’ve found that the best way to keep unused code out is to have proper interfaces between the application components (Phoenix Context are an example) and manually check (using the editor search across the project) that functions in that interface are being used from somewhere.

1 Like
11

Thanks for the help… definitely I wasn’t expecting dynamic function calls (i.e. apply) to be easy to detect but thought the compiler or xref could maybe find unused functions referenced by static calls.

Agree also on your last point… just being a bit lazy. I will manually go through all public interfaces (contexts) and use VSCode’s “Find All References” to see where they are called and make sure all private functions are properly defp.

Finally definitely agree on having a good test suite to ease refactoring… then you can use ExCoveralls also to uncover functions that are not used (or at least not tested).

1 Like