Finding "dead code" in a large C++ legacy application [closed]_问答_开发者

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answe开发者_C百科rs.

We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.

Closed 6 years ago.

Improve this question

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?

You'll want to use a static analysis tool

StackOverflow: What open source C++ static analysis tools are available?
Wikipedia: List of tools for static code analysis

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 can break something that you didn't know used the code.

You can use Cppcheck for this purpose:

$ cppcheck --enable=unusedFunction .
Checking 2380153.c...
1/2 files checked 0% done
Checking main.c...
2/2 files checked 0% done
[2380153.c:1]: (style) The function '2380153' is never used.

Caolán McNamara's callcatcher is very effectively used within the LibreOffice project (~6 MLOC) to find dead code.

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:

Coverage meter
BullseyeCoverage

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.

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 rid of the dead wood, one will find your team maintaining the stuff for years.

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.

See our 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.

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).