The first time you run an analysis tool on a codebase, you may well find that it reports a large number of issues - far too many to deal with immediately.
This is the well known "noise" problem, and is a reflection of the fact that although the knowledge of certain classes of analysis issues may be essential to one organisation they may not be at all important to another - and vice versa. It is therefore extremely difficult for an analysis tool to present an appropriate warning policy "out of the box".
It follows that it is highly desirable to tune your warning policy to reflect your own needs, and refine it as your codebase evolves.
Despite the "noise" they tend to generate, those early analysis runs will give you the information you need to do this since from them you will be able to see which analysis issues are being identified within your codebase, and how often each is occuring. You can then decide which issues you initially wish to include in your warning policy, and which to disable.
There are two basic approaches you can use:
As the codebase evolves over time, the corresponding warning policy should do likewise. In a team environment it follows that it is advisable that someone within the team takes ownership of and manages this process on an ongoing basis.
The way the warning policy is defined is tool dependent. For example, in the case of PC-lint the normal method is to include +e and -e directives in an options.lnt file defined on a global, solution or project specific basis. Please contact us if you need assistance setting up a warning policy for a specific analysis tool.
In Visual Lint Enterprise Edition you can also configure the global Display Filter to selectively enable and disable specific issues without re-analysing the codebase.