Effective technique to reduce and eliminate warnings in a large code base?

Question

I have been involved in the development of large code bases that grew to millions lines of code over the course of multiple years and where the amount of warnings grew out of control because it was not a concern for the initial developers. Technical debt accumulated and now, I would like to pay it back.

Do you know of any process, method, or steps to decrease this type of technical debt and make sure that it remains in check once it has been eliminated?

How would you attack the problem of large numbers of warnings? Would you eliminate warnings in low level libraries and work your way up? Start with high level libraries first? One type of warning at a time? Do you involve one individual? One team?

I am looking for practical experiences with this type of problem and I am equally interested in what worked and what did not work.

EDIT: Language used is C++.

Answer 1

I try to correct these issues as I see them. If I check out a file, I try to correct any warnings.

In some of our smaller class libraries I have gone through and tried to eliminate all of the warnings in the entire project, but that is not always practical for larger projects.

Answer 2

You may be able to automate the correction of some warnings. I wrote a Ruby script to take the compiler's list of "unused parameter" warnings and suppress their warnings by commenting out parameters' names in our event handlers' definitions (since the parameters were expected by our framework but weren't actually used). Other unused parameters can be removed entirely with a good regex. Another Ruby script removed unused local variables from the compiler's list of warnings. None of the scripts are anywhere near a full-fledged C++ parser, but I was able to take advantage of our code base's style to simplify the task.

Answer 3

I would classify the warnings in terms of severity and start with those.

Perhaps a tool such as PREFast, which targets C++, could help. There is even a version targeting drivers.

Answer 4

I inherited a large code base, in PHP, and the persons who had developed it had done a terrible job and ignored any error that didn't make the code fail, the first run through ZEND produced some 1538 warnings and notices.

My developers were less the enthused when I told them that we were going to fix them, and they didn't want to do it, so I added an error handler that would die() on ANY error and wrote it to a file they did not have write permissions to, while that is a bit extreme, what you might want to do is start catching the errors and forcing them to be fixed when they occur, it might be painful for a while, but it can pay off in the end.

Answer 5

For warnings that are determined to be completely benign, you can update your build procedures to suppress them across the entire codebase. You'll know these immediately when you see them. Most compilers support the ability to suppress certain types of warnings. This should eliminate a lot of the noise, allowing you to focus on the more important ones.

For the rest, you'll probably need to enforce a policy that requires a component to be completely warning-free (besides ones on the automatically suppressed list) to be considered successfully built, since your code base is so large. Over a reasonable period of time, the majority of components should have at least one change that needs to be made to them, and it shouldn't be too painful to clean up the warnings for each component before checking in the first modifications after instituting this policy. This guarantees that the primary components which are under active development will be cleaned up first; legacy components without any recent changes should be a lower priority. Fix the highly visible broken windows first.

Answer 6

We had a similar problem many years ago with a code base we inherited, many thousands of warnings that we wanted to get rid of.

We drew a line in the sand with some scripts. We basically stored all the warnings in a file (an exclude list) so that, when we compiled the file, those warnings were stripped from the output (since we didn't care about them).

Whenever a file was changed (new functionality rather than minor bug fixes), the rules were:

• no new warnings could be added to the exclude list.
• The first 5% of warnings were removed from the exclude list.
• The file had to compile warning free (apart from those still on the exclude list.

The script was a tricky one since it had to handle warnings changing lines but, since we were adding none and removing a consecutive chunk, the warnings were still in the same order (so we just ignored line numbers).

That way, you had a gradual process of removing the warnings and the third rule prevented any new warnings from being added, even after the exclude list had gotten down to zero.

Needless to say, it took quite a few iterations but we identified many instances of warnings (in the 100's) that were caused by a single line of code.

We also had a bonus system (a day off with pay, not drawn from holiday leave) for those that managed to remove all warnings from a file so it was advantageous to remove the last three rather than leave it for the next guy.

Answer 7

There are several good techniques mentioned in this old question:

http://stackoverflow.com/questions/183788/c-c-compiler-warnings-do-you-clean-up-all-your-code-to-remove-them-or-leave

Answer 8

I've worked on codebases like that and it does tend to annoy me if you can't see the wood for the trees, warning-wise, or people turn off the warnings because "there are so many of them".

What I did the last time I worked on a codebase like this was to capture the output of a full build with all the warnings. I then wrote a small script that sorted the output in decreasing order of the number of occurrences and spent a day or so fixing the top 10%-20% of them. A lot of them were in header files admittedly, so knocking a few of those on the head lowered the warning count by about 30k within a matter of hours. From then onwards, I worked on the premise that if I had to touch a file, I'd go and fix the warnings in that particular file. I convinced the other developers to adopt that policy as well and within a couple of months, having warnings turned on actually became benefical again, plus the quality of the codebase had improved.

Answer 9

Set up a Hudson Continuous Integration Server with the warnings and game plugins.

Now, you can have a contest among the developers:

1. Removing warnings adds points.
2. Adding warning deducts points.

Make the score board the home page of everyone.

Answer 10

I'm working on a twenty-year old code base and hammering on the warnings - about 12,000 warnings on the not too fussy machines.

Sometimes, it turns out to be easy to get rid of a lot of warnings with a small change. Just this week, I fixed a method (well, pair of methods - let's not get distracted by the copy and editing that's gone on) that was declared to take a char * but was being passed __FILE__; the C++ compilers did not like that. Since the only thing the method did was copy the name into a private buffer, there was no harm in making the parameter const char *, and that removed about 600 warnings from the build. It wasn't in 'my' code or code I'm tasked with looking after; it was making my build worse than it should be. There's another similar function - similar problem - that is taking more time to get reviewed by the owners. (There was an interesting 24-line repeated set of #define plus comments in the header - that I missed on first pass, and everyone else who'd looked at it had missed for about 5 years.)

The main problem is getting people to be concerned about warnings. I refuse to leave a file which I edit with more warnings than when I started; I aim to get the number down to zero. Most people aren't so fussy - they feel more pressured by management to get things done without attending to such niceties. One advantage of being more senior is that there is less of that pressure on you.

Answer 11

if you are using C#, then you should install resharper and get to work

Answer 12

Do you know of any process, method, or steps to decrease this type of technical debt and make sure that it remains in check once it has been eliminated?

How do you build a pyramid? One stone at a time. Whenever you touch a file, fix a warning or two in it. Once warnings are eliminated in the "popular" files, just fix the top one in the build log.

Assign a person to annoy programmers who introduce new warnings until they are fixed.