Day 4 - Excise some unused code

Let’s track down some code that’s not actually in use (and delete it, naturally).

Those of you with statically-compiled languages will probably have little to do today, but in dynamic languages like Ruby and JavaScript, it’s pretty easy to end up with unused code laying around.

To track down your unused code, I recommend a tool like unused: I’ve personally used it to good effect in Ruby, and I believe it will work well with JavaScript and Elixir (see the docs).

If you have a different method for finding unused code that works well for you, please share it here so others can benefit.

As always, please share your results. I’d love to hear how many lines you manage to excise.

Almost done with week 1! Keep it up.

1 Like

Difficult one for me. Unused failed with an error after 10mins of compiling on my Mac. Some issues with an undeclared identifier so I didn’t bother any more with it.

Instead I went through some of my biggest javascript files and removed some unused variables. Netbeans underlines them in file, but not always correctly, so you have to be very careful when removing them.

Beside that I spent my 20mins+ researching for solutions and quickly tested some online tools like but that doesn’t even correctly identified my mixin patterns beside not being practicable for daily use.

All in all an unsatisfying result today.

In the Jetbrains suite of IDEs, right click your project or whichever folder you want to check, click Analyze-> Inspect Code…, let it run and scroll down to the ‘Unused’ section in the results.


I’d heard of Unused before, but finally got round to installing it this morning. For some reason, it only returned javascript methods, including things in jQuery that I’m not using (this is a Rails app that makes only light-to-medium usage of React).

I’ll try and spend some time looking into this, but if anyone has any pointers they’d be appreciated!

Installing unused and learning how to create ctags took most of the time.
I don’t use ctags so if you are like me you can find interesting informations on this blog post.
To generate ctags on a rails project :

$ ctags -R --languages=ruby --exclude=.git --exclude=log .

Then run:

$ unused -a

No unused code on the project I tested :wink:


Done exactly the same as @mpalma :slight_smile: for our Rails project… and also got Unused found no results after about 30 minutes of scanning which surprised me a little…

I’m also wondering if my unsed configuration was optimal for a Rails project. What do you usually put in your ~/.unused.yml file?

So reading the unused doc, I’ve done the scan doing the following:

And this this time I got an output about my code… I now have to investigate about what occurs once exactly means…

1 Like

Just to add to that: There might be a few additional steps depending on your configuration:

@trufflepiggy On my mac I did this to use unused

Btw at consul we’ve many possible unused code by some are false positives but I can’t find a way to “ignore” them as rubocop allows with .rubocop_todo.yml file :thinking:

1 Like

@bertocq Thanks for the tip. I already got an error during installation via brew so I didn’t even had a chance to try to run Unused. May gonna dive into the issue at a later point.

unused found one old unused class. Thank you for the exercise.

Since we already analyze test coverage, it was quite easy to find some unused code that could safely be removed by going though the test helpers. Since the project is a library and Ruby makes it way too easy to expose API surface without intention, for actual application code it was sometimes hard to tell if code was simply untested, but still used by some external client.

There is also an old but good blog post by Mayron Marston on ways to use test coverage for dead code detection.

Didnt manage to use unused as expected for php/laravel, but when I looked in the project I found by myself Repository Pattern files, which are not used and remove all of them.

Yesterday I had the pleasure of submitting a PR that removed > 10,000 lines of dead code, related to a major feature we are removing. It was a long process of grepping the codebase for keywords, methods & classes.

As for Unused, to get it to show me anything relevant I had to add the tags file to my .gitignore (see the docs). I also used the git-based ctag generation method mentioned above - thanks! Going through the results now.

Update: removed an extra 200 lines!

1 Like

Huge fan of Unused. We use it on our main Rails repository but this morning, I took the time to use it on our secondary Rails application. I like to output the results as text files based on the file type.


$ rm -rf .git/tags
$ ctags -f .git/tags -R $(git ls-files | grep .js)
$ unused -s -g none >> unused_js.txt


$ rm -rf .git/tags
$ ctags -f .git/tags -R $(git ls-files | grep .scss)
$ ctags -f .git/tags -R $(git ls-files | grep .css)
$ unused -s -g none >> unused_css.txt


$ rm -rf .git/tags
$ ctags -f .git/tags -R $(git ls-files | grep .rb)
$ unused -s -g none >> unused_ruby.txt


$ rm -rf .git/tags
$ ctags -f .git/tags -R $(git ls-files | grep .haml)
$ unused -s -g none >> unused_haml.txt

Before deleting, I use Rubymine to make sure the code is not being used in the app (like a Ruby Helper being used by a HAML view).


Finally got rid of one of the 2 things in our monolith app that was using a different persistence layer than the rest of the application that has been unused since 2010. The last section of code on that other layer has a future story to be broken out into its own app, so persistence consistency is insight!

This one wasn’t super fruitful for me. Our codebases (or at least the ones I live in) are primarily Python so unused wasn’t a tool I could use. I instead found Vulture ( and ran one of our microservices through it.

It returned a ton of false positives, though one of the things that’s nice about it is it gives a confidence rating (ie “60% confident it’s unused”, “80% confident” etc) and you can give it a minimum confidence cutoff (ex: vulture somecodebase --min-confidence=90 will give only things it’s 90% sure (or better) are unused. For us there’s a ton of convention code as it’s a project based on Django so things like attributes on views or forms can get flagged as unused (as there’s some magic Django voodoo that makes those properties into actual things that are very much used). It also looked at our migration scripts and since those are machine generated (but in version control) there’s some stuff there it flagged as well.

In any case, found a method in our test suite that was no longer needed, a couple unreachable lines, and some commented out code that all got turfed.

This is one that’s tricky to do safely in a dynamic language – I’ve personally been bit by that “oh there’s no way this is used anywhere…oh crap” moment more times than I can count, so I’d advise erring on the side of caution on this challenge – if you aren’t sure, ask someone more familiar with the codebase if it’s cool to go or don’t delete it.


Actually got rid of some code doing the TODOs. Most of the unused code I found today was actually there for planned future development, not dead code, just not alive yet. Still a good task to run through!

A good way to identify the dead code in productions is to know which all classes are not instantiated,

Michael Feather have written good tool to figure out just that. (check out

Here is my attempt to adapt the same concept in .Net (

Hope that helps.

1 Like

I had a few warnings at first, but realized that it was flagging some javascript in my assets/bower_components folder. After reading up a bit on excluding folders from ctags I came up with:

$> git ls-files | xargs ctags --exclude='app/assets/bower_components/*' && unused

Lucked out again today - nothing found! I’m a bit surprised.