3 ms·
Static analysis is rarely helpful after the fact. Its usefulness is directly related to its entry into the project timeline. Just like "handle all warnings, a
by fit2rule 10y ago
Static analysis is rarely helpful after the fact. Its usefulness is directly related to its entry into the project timeline. Just like "handle all warnings, always" is a generally good mantra, having static analysis is supposed to keep you ahead of the curve. If you don't do it early, and often, you're not doing it properly.
Also, having these tools, but no coding rules by code contributors, enforced with real code-reviews and reviewer(s), will also deliver 'not worth it' results. Its a process, not a chisel.
- mikeash 10y agoThat doesn't match what I've seen. When Apple added support for the clang static analyzer to Xcode, a ton of Objective-C programmers started running it on their code bases, and among those I know, it found a ton of bugs that had gone dormant for years.
- fit2rule 10y agoSure, of course it'll find bugs after the fact. But the value to the project in doing static analysis is in not adding bugs in the first place, because you caught them with static analysis as a standard part of your development process. Who knows what those unknown bugs cost those developers over the years ..
- mikeash 10y agoAre you implying that there is no value in finding bugs after the fact? Sure, it's better to catch them up front. But catching them later is still extremely valuable.
- fit2rule 10y agoCatching them before they're deployed anywhere is the point. Deploying quality software from 1.0 is a different order of value than 'experience improved for the 1.1 user because: bugs fixed'. Both circumstances have value: I meant only to state that static analysis should be up-front, to get the absolute most value out of it, because it will massively improve your software quality to have it there.