After running integration-time static analysis, software engineers should have a stronger sense of potential systemic problems in the code. The next step is to run CI static analysis to enforce the coding policy outlined in the planning phase. This prevents the types of defects discovered during integration-time analysis.
For every issue discovered in static analysis, there are at least 10 more of the exact same thing in other places in the code. Static analysis is the ideal tool for addressing all violations of the same kind at the same time. This is opposed to chasing every possible path through the code. It’s far better to find the systemic problems in order to create an environment in which bugs cannot survive.
When we talk about static analysis, in many cases we mean anti-pattern analysis. A positive pattern is something that should be in the code. For example, a policy that requires engineers to use a typedef when declaring function pointers is a positive pattern static analysis rule[1]. This is in contrast to a policy that, for example, prohibits the use of the data() member function from a string class when interfacing with the standard C library.
refer to: http://embedded-computing.com/articles/getting-leveraging-right-static-analysis/
沒有留言:
張貼留言