"visual studio" entries

Complement a good testing program and identify hard-to-find bugs with static analysis.

Static analysis is, quite simply, any analysis you perform on software without actually running it. (Analyzing software as it runs is dynamic analysis.) There are many reasons to do static analysis, but almost all of them boil down to the desire to improve software quality. As a designer of developer tools, improving software quality by any means is keenly important to me.

Let’s consider compiler warnings. They are produced without executing the code, so the compiler is doing static analysis. Their aim is to inform the developer that the code, though legal, is probably wrong. Suppose you were a compiler developer and you wanted to add a new warning; what characteristics must that warning have?

There must be some statically identifiable pattern to the suspicious code.

The pattern must be common and plausibly written by a developer; developing a warning for a too-rare pattern or completely unrealistic code is effort that could be better spent on other features.

The warning must have a low “false positive” rate; a warning must actually identify defective code more than, say, 99% of the time. False positives encourage developers to eliminate the warning by turning the warning off, or worse, by incorrectly changing the code. There must be a way to eliminate the warning without introducing a bug into the code.

The pattern must be identified extremely Slowing the build process by anything more than a few percent is unacceptable.

I always recommend that everyone use the strictest warning settings on their compiler, to pay attention to warnings, and to (carefully) fix them all. Even fix the false positives; if the code was weird enough to fool the compiler then it’s weird enough to fool a human, and you don’t want to have “expected” warnings distracting you from actual warnings.Read more…