In response to Jason’s post about false positives. First of all there is a general misconception of false positives. Modern static source code analysis tools have changed the game. It is not the Lint tool of the past, a focus with deep inter-procedural technology has placed the requirement that static tools today produce more real issues than false reports.
With that said, Jason is right, large code bases never running static analysis will produce a large number of issues no matter how accurate it is. Even though static analysis tools do provide a number of ways to manage this (and Jason talks about one) it does make sense to put this in your code reviews. You are looking at legacy code but if you are doing code reviews then you must have changed something with that legacy code. Therefore having those bugs visible to you during the code review could suddenly now apply.
About the Author: Alen Zukich
Hello, I'm Klocwork's Director of Product Management responsible for the company's product direction. I’m an Electrical Engineering graduate and CSPO. I’ve been with Klocwork for over a decade now including the time before we spun out. My passion is in the development tools space, so expect content related to software development. Related Posts
-
DevOps adoption grows as companies look to cut costs, improve software security
DevOps, the development approach that merges the development and operations teams to overcome deployment bottlenecks, is seeing a... -
Does a password tool’s encryption weakness highlight the need for more code review?
A guessing technique that leverages a design flaw in the popular 1Password password manager tool has sparked widespread... -
Are developers ready to embrace Android as a gaming platform?
Android is the most widely used mobile operating system, giving developers looking to reach a large audience a strong incentive...
Interestingly, some organizations use “false positives” as an opportunity to flag code that should be rewritten. Modern static analysis tools are pretty sophisticated and so code that trips up the analysis can be indicative of code that is overly complex and difficult to maintain. The rocket scientists at NASA use the “Power of 10″ rules, one of which states that not only should they fix problems coming from static analysis tools, but also “fix” the code so warnings/false positives go away. This process may not be for everybody, and sometimes there are real false positives which should be ignored, but the point is that false positives may be indicative of something more than a deficiency in analysis. For more on the power of 10 visit http://codeintegrity.blogspot.com/2010/08/power-of-10-for-safety-critical-code.html