I work on a C++ project that generates bajillions of warnings. Most of the warnings appeared after the code was written:Initially the project used Visual C++ 8, soon switching to 9, but there is little difference in the generated warnings. Warnings were either fixed or silenced, so there were no warnings then.Then a 64-bit target was added. It generated a huge amount of warnings, mainly because of sloppy use of types (e.g. unsigned vs. size_t). No one bothered, or had time, to fix them once the code worked for the purpose.Then support for other platforms using GCC (4.5 and 4.6, some 4.4 initially) was added. GCC is much more picky, so it generated many more warnings. Again nobody bothered, or had time, to fix them. This was complicated by the fact that GCC didn't have a pragma to silence a warning in particular bit of code until 4.5, and according to the documentation it is still not what one would need.In the mean time some deprecated warnings popped up.So now we have a project generating thousands of warnings. And I can't even say from how many places, since even .cpp files are compiled several times by different compilers and warnings in headers get printed over and over.Is there a best practice for cleaning up something like that? Or at least some positive experience dealing with it?
How to deal with warnings in a legacy project
legacy;integration;warnings
Don't touch any of the legacy code. Find a way to suppress the warnings for now. Making seemingly innocuous changes to the code can introduce bugs in code which, I assume, has already been tested and is relatively bug free.By suppressing all of the warnings that are currently in the codebase, you can pretend to have a clean slate. Any new warnings introduced into the code should be eliminated, and when old code is rewritten the new implementation should not suppress warnings.Your goals here should be:Reduce the signal/noise ratio. If developers see thousands of notices when they build, they aren't going to notice that the master branch has 2004 notices and their branch has 2006. Don't introduce any more bugs. By making the aforementioned innocuous changes, you could be introducing unforseen bugs. This is especially pertinent when you have thousands of warnings. Even if your error rate is incredibly low, you still have thousands of chances to screw up.Don't let the legacy code lower your standards for new code. Just because the warnings for a class were suppressed doesn't mean that the new class can do the same. Eventually, with diligence, the legacy code will be eliminated from the codebase and replaced with newer, warning-free code.