5

We have a large "legacy" C++ code base on which no static analysis is run at the moment.

Every now and then, we are thinking about at least using cppcheck, maybe via Visual Lint. (I've also briefly checked the sites of Coverity or Klocwork or RedLizards/Goanna.)

However, I do expect a huge number of found warnings and probably also false positives (in that the error does not actually cause an observable bug in the application).

We simply do not have the resources available to address these all on rollout of any analysis tool, especially as we would very much only like to touch "code that works (well enough)" if we really have to.

So what I am looking for are experiences and user stories of adding C++ static analysis to legacy code bases:

We had this product, consisting of xxx lines of code over zzz C++ projects and we started using static analysis tool yyy in development. Rooting out the legacy code warnings took aaa effort, (temporarily) ignoring them was hard/easy/impossible. Ignoring warnings selectively for the code base really worked well/didn't work at all. Etc.

Something like this. Thanks!

|improve this question

closed as not constructive by user40980, user7007, World Engineer, Blrfl, gnat Feb 24 '13 at 7:43

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

6

For each of these tools you can select which classes of warnings you want to see, and which to suppress.

I've got some experience with Klocwork, and the granularity of the selections there is pretty good, as well as the actual reporting, i.e.: you can filter out the "old" errors, and only see the incremental changes, when you run the tool on the changed code. I find it very convenient and useful.

However, a point for consideration:

However, I do expect a huge number of found warnings and probably also false positives (in that the error does not actually cause an observable bug in the application).

Sometimes, although the error doesn't cause an observable bug in the application now, it might bite you in the future. Seen that happening and it was painful. Ignoring errors just because they don't cause visible damage right now is not a good idea.

Prioritize and manage your time of course, but don't just ignore the errors and forget about them, they tend to remind you of their existence in the least appropriate moment.

|improve this answer
  • 1
    Thanks for the info you can filter out the "old" errors, and only see the incremental changes .. that is certainly useful. I was/am concerned that some tools would require source-code tagging to achieve this. – Martin Ba Sep 30 '11 at 9:50
  • No, at least for Klocwork, you can configure reports to be incremental. – littleadv Sep 30 '11 at 9:55
  • I have used both Klocwork and Covertity, and on both the "issues" are kept in a separate database and can be set to different levels of importance (i.e. Fix Now, Future Release, Not an Issue, False Positive). Some of the other, cheaper tools (like PC Lint) don't keep a database of issues and instead just report what they see each time they are run. – jwernerny Sep 30 '11 at 14:11
  • 2
    +1 for noting that "not seeing it now" does not mean "won't see it when it's very inconvenient to fix and is keeping our biggest customer from being able to ship his products." – jwernerny Sep 30 '11 at 14:11
3

I went through this several years ago (introducing lint to a 12-year-old legacy code base). Although I ended up with an overwhelming flood of errors, I decided to ignore the problems which were most common (with hundreds or thousands of instances), and concentrated on the messages which occurred only a small number of times, my logic being that a lint problem found in hundreds of places is probably harmless (it's possible that all the observable problems had been fixed, but more likely the message is just noise), but problems I saw rarely might be genuine problems we'd never had reported.

This lead to fixing some shocking array boundary problems and loop problems, and then I ended up disabling messages for the most common problems.

Awk and I became good friends as I analysed lint output. I'd use perl now if I were to do it again.

|improve this answer
2

Here are some studies on cost-benefit of static analysis tools.

http://collaboration.csc.ncsu.edu/laurie/Papers/TSE-0197-0705-2.pdf

The gist of the study is that static analysis tools are in the same order of magnitude of cost/benefit ratio as inspection on an established code-base. In the end, the cost of finding the bug was about 1/2 inspection (but this is obviously highly dependent on the code-base - and why they concluded that the cost was in the same order of magnitude).

|improve this answer
  • 1
    Link only answers are bad answers. If the pages linked to go missing then the answer becomes useless. If possible please summarise the pages you link to here. – ChrisF♦ Feb 23 '13 at 22:54
  • @ChrisF Understood -- I looked it up for myself, and didn't think about future. It's edited now. – Dale Feb 23 '13 at 23:23
  • Thanks. You can leave the links in for reference (in fact you probably should) – ChrisF♦ Feb 23 '13 at 23:25

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