views:

468

answers:

7

I'm currently working on a large and old C++ application that has had many developers before me. There is a lot of "dead code" in the project, classes and functions that aren't used by anyone anymore.

What tools are available for C++ to make a analysis of large code base to detect and refactor dead code? Note: I'm not talking about test coverage tool like gcov.

How do you find dead code in your project?

A: 

Although not specifically for dead code, I found the Source Navigator

http://sourcenav.berlios.de/

quite useful, although cumbersome to set up and a bit buggy. That was a year ago on Linux (Fedora).

Schwanritter
+6  A: 

You'll want to use a static analysis tool

The main gotcha I've run into is that you have to be careful that any libraries aren't used from somewhere that you don't control/have. If you delete a function from a class that gets used by referencing a library in your project you'll jack whoever consumes your library.

Alan Jackson
A: 

One approach is to use "Find All References" context menu item on class and function names. If a class/function is only referenced in itself, it is almost certainly dead code.

Another approach, based on the same idea, is to remove(comment out) files/functions from project and see what error messages you will get.

hongliang
+1  A: 

I think your best bet would probably be a coverage tool. There're plenty for both *nix and windows. If you have unit tests, it's easy - if you have a low test coverage, then the uncovered code is either dead or not tested yet (you want both pieces of this info anyway). If you don't have unit tests, build your app with instrumentation provided by one of those tools, run it through some (should be all ideally) execution paths, and see the report. You get the same info as with unit tests, it will only require a lot more work.

Since you're using VisualStudio, I could provide you couple of links which you could consider using:

Neither of them is free, not even cheap, but the outcome is usually worth it.

On *nix-like platforms gcov coupled with tools like zcov or lcov is a really great choice.

Dmitry
+1  A: 

I will go against the stream here: were you going to use any static analysis on my code, you'd find a lot of dead code... although almost everything is used.

What's the catch ? I use a lot of indirections to keep dependencies to a minimum. The classic is to think about a MVC framework:

// myAction.cpp
MyAction gMyAction("MyAction"); // auto registration of exemplar

// ... define MyAction methods

What's the result ? The only references to MyAction are located in MyAction.hpp and MyAction.cpp... yet it's used.

Thus, I would recommend a run-time analysis. Tools like gcov will indicate you the parts of your code that have been run:

  • clean up your unit tests (in accordance with your business analysts)
  • run them with gcov monitoring your binary
  • tread through the report to distinguish code that is not tested (and should be) from dead code
Matthieu M.
+2  A: 

Nothing beats familiarity with the code. Except perhaps rigourous pruning as one goes along.

Sometimes what looks like deadwood is used as scaffolding for unit tests etc, or it appears to be alive simply because legacy unit tests exercise it, but it is never exercised outside of the tests. A short while ago I removed over 1000 LOC which was supporting external CAD model translators, we had tests invoking those external translators but those translators had been unsupported for 8+ years and there was no way that a user of the application even if they wanted to could ever invoke them.

Unless one is rigourous in getting ride of the dead wood, one will find your team maintaining the stuff for years.

lilburne
A: 

See SD C++ Test Coverage.

You need to do a lot of dynamic testing to exercise the code, to make sure you hit the maximum amount of coverage. Code "not covered" may or may not be dead; perhaps you simply didn't have a test case to exercise it.

Ira Baxter