The war on Murphy

[nancylebov]

Found here:

It is common to take a sort of smug satisfaction in reports of colossal failures of automatic systems, but for every failure of automation, the failures of humans are legion. Exhortations to “write better code” plans for more code reviews, pair programming, and so on just don’t cut it, especially in an environment with dozens of programmers under a lot of time pressure. The value in catching even the small subset of errors that are tractable to static analysis every single time is huge.

I noticed that each time PVS-Studio was updated, it found something in our codebase with the new rules. This seems to imply that if you have a large enough codebase, any class of error that is syntactically legal probably exists there. In a large project, code quality is every bit as statistical as physical material properties – flaws exist all over the place, you can only hope to minimize the impact they have on your users.

In case you were wondering, static code analysis is what you can find out about what's wrong without running the program.

Fair warning: as is sometimes the case, I'm posting this because it sounds interesting and reasonable, not because I'm able to evaluate the technical details.

Link thanks to andrewducker.

Comments

[metahacker.livejournal.com]

As a Java advocate--and possibly to start a flamewar in your comments--I note with some satisfaction that the top two categories of error found in their C++ codebase are simply impossible in Java, the language having been built to eliminate them. Static analysis is good, and a step before it is proper language design and enforced best practices.

This isn't to say Java doesn't have plenty of ways to have fun run-time errors, just that the design...worked.

Interesting essay; given that my day job involves building UIs to help our programmers cope with the inherent defects that they are GOING to create, it's always cool to see other people recapitulate the challenges we face.

I disagree with a lot of his conclusions, but I suspect his workplace has different constraints than mine. E.g., to us, it's vital to make sure our internal tools are as bug-free as possible, because bug impact there is multiplied when the tools get used for the next N years by our developers to write customer-facing code. He de-emphasizes these, which says to me his workplace is focusing on short-term profits over long-term.

[andrewducker]

Java still has all sorts of problems that are well served by static analysis tools (we use a lot of them in my work), and null references are a major source of errors if you're not careful. One of the tasks we have to carry out as part of all of our development is to check the results from Findbugs,Checkstyle, PMD and Fortify for Java (and similar tools for C#).