I've started in a company that has been developing an app for 4 years. They haven't used any static analysis tool until now so if we include them we will have tons of warnings.

Do you know how can we integrate these tools in a way that we get warnings somehow only in new code and we extend their usage to the rest of the code bit by bit?

Edit: the tools to use are FxCop and StyleCop, both for C# in case it matters but anyway I think the solutions proposed can be adopted as well.

  • Run the analysis. Save off all the warnings, in a db or custom file maybe. Run the analysis on "new code" and only show warnings that don't match the saved warnings. Start wiping out the saved warnings so they show up in the analysis output? – Patrick Hughes Oct 5 '15 at 8:20
  • Another approach might be to run the tools against the existing code base and attack it rule by rule. – Robbie Dee Oct 5 '15 at 9:45
  • What tool(s) do you have in mind? As for the free (FLOSS) Cppcheck, there is some support, see my answer. – Wolf Oct 5 '15 at 11:04
  • 1
    Edited the question to include the tools to be used. – Ignacio Soler Garcia Oct 5 '15 at 11:16
  • 1
    If you are building on TFS, StyleCop can be built in so you can start setting a maximum number of failures as a high water mark. New code is then either submitted clean or devs are forced to clean up some legacy code first. – Robbie Dee Oct 5 '15 at 12:08

What I did with Cppcheck was to format the output with the same format as used in a suppression file, then I just copied the lines. With this tool, it is also possible to use patterns (single checks, whole files) for suppressions. (My personal advice: Don't suppress checking "old code" if you are not able to ensure that it will never get touched.)

Cppcheck also provides parameters that let you concentrate on the errors and warnings first. In all projects of our company, that Cppcheck was used on for the first time, it found errors. So don't skip the stage of understanding the checking results for old code.

If interested in details, the command line help is more straightforward than the online manual.


Although you don't say which tools you use (Fortify is different from cppcheck for example) most tools allow you to specify which code files to operate on. Specifying only new files will allow you to check new code without looking at the old, but obviously only if you put all new code in new files. This is not going to help in bugfixing but you could migrate any changed code to one of the new files as changes are made. This will introduce old functions into the analysis but might not be such a bad thing - if you bugfix a function, you also have to fix up all the other warnings too.

But I think that's a lot of effort that belongs in a DailyWTF article. Analyse the entire codebase, take a day to fix the low-hanging fruit of warnings you get and then allocate the more difficult fixups as bugs to be fixed when you can.

Remember those warnings the analysis tools report are still potential code errors, its best to fix them regardless.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.