Slashdot Mirror
Ask Slashdot: What Tools To Clean Up a Large C/C++ Project?
An anonymous reader writes I find myself in the uncomfortable position of having to clean up a relatively large C/C++ project. We are talking ~200 files, 11MB of source code, 220K lines of code. A superficial glance shows that there are a lot of functions that seem to be doing the same things, a lot of 'unused' stuff, and a lot of inconsistency between what is declared in .h files and what is implemented in the corresponding .cpp files. Are there any tools that will help me catalog this mess and make it easier for me to locate/erase unused things, clean up .h files, and find functions with similar names?
If you're company is willing to pay for it, you can get something like Coverity. On the free(as in beer) side there is CppCheck and clang.
scan-build and scan-view from clang++ will show you what is being used and what isn't as far as static code analysis goes.
graphviz can visualize the inter-functional and inter-file dependencies.
It's free and built into the functionality of doxygen.
I'd recommend recommenting all the functions using doxygen - because to clean up a large project you need to know it.
You didn't mention a version control system, so assuming you aren't using one:
Turn it into a git repository so you can easily back out of changes.
Then run doxygen and start reading through the documentation.
This will find the static interaction points, but will miss the dynamic interaction points. He also has to watch for callbacks and methods present to satisfy oddball templates in C++, methods that will be invoked as a result of casts, etc.
1. Modern IDE with good gcc parser: Eclipse, Netbeans, 3rd party paid ones. Not Visual Studio. You want it to build call hierarchy tree for you, so that you can find methods that are unused. It will require some manual steps
1a. if you have $, Understand for C/C++ is proprietary tool that will map a hierarchy of your code.
2. perform structural coverage analysis of code in live action, will help map the dead code. gcov is free if you can use it.
Compiler warnings have mostly caught up with the capabilities of Lint. There are some things Lint still does, but there are lots of things it warns about that have, as far as I know, never been the cause of a real bug. Getting a project to be 100% warning free with gcc -Wall is possible, and usually possible with -Wextra (maybe not so much with g++). The warnings usually are valuable, and I've personally seen bugs that could have been caught with gcc's warnings. Other compilers have other warnings and personalities, but I think it's worthwhile to investigate using warnings to check out a project with any compiler.
“Common sense is not so common.” — Voltaire
-1-
Install "OpenGrok" ( https://github.com/OpenGrok/OpenGrok ) and index your code.
OpenGrok is the best source-code browsing option out there.
Use OpenGrok to extensively read and understand your code based.
Examples:
Which files in the linux kernel call 'printk':
http://lingrok.org/search?q=printk&defs=&refs=&path=fs%2F&hist=&project=linux-next
Where is 'printk' defined?
http://lingrok.org/search?q=&defs=printk&refs=&path=&hist=&project=linux-next
-2-
Use Clang's static code analyzer, 'scan-build' : http://clang-analyzer.llvm.org/scan-build.html .
Depending on how good/bad the code is, there could be many false positives.
but it will give you a sense of what's going on, and what to focus on.
-3-
Enable all possible compilation warnings (either in GCC or CLANG).
The more the better. Use "-Werror" to ensure you don't ignore them.
Do it iteratively if needed by enabling more warnings, fixing what breaks, and repeat.
A good list is here:
http://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/manywarnings.m4#n103
Especailly eliminate unused code and variables.
-4-
Analyzer the McCabe Complexity ( http://en.wikipedia.org/wiki/Cyclomatic_complexity ) of your code, using pmccabe ( https://people.debian.org/~bame/pmccabe/pmccabe.1 ).
Focus on functions with too-high score, and re-factor them.
-5-
Add automated tests to your program, and combine it with code coverage (lcov/gcov).
In addition to the general good advice of 'try to increase coverage', focus specifically on code sections
which are critical but not covereged at all - write tests specifically for them.
Having some tests is better than having no tests at all.
-6-
Decide on code style (e.g. linux kernel style, GNU style, any other style) and build shell commands to tests them (i.e. a combination of grep/awk etc.).
New commited code should adhere to the style. Use git hooks to enfore it.
Existing code should be (slowly) refactored to the new style.
Which style is a matter of personal preference, but having a consisted style across all code really helps.
Ideally, it should be something as easy as 'make syntex-check' in GNU Coreutils.
-7-
With all of the above, integrate the tests into an automated system (e.g. autotools or cmake or just makefiles) that will allow you to run and re-run and re-run these checks easily.
If it takes 10 shell commands to do static analysis - you'll be too lazy/busy/whatever to do it more than once.
It should be as easy as 'make static-scan' or 'make coverage'.
Investing in writing a good makefile is worth the effort.
Good luck.
- gordon