Static Analysis – Difference Between Linter, Sanitizer, and Static Analysis Tools

I worked at a place that used a commercial static code analysis system called Coverity Prevent, and it was freaking amazing! It's really sophisticated and intelligent.

We threw about 18 GB of both open-source and proprietary C and C++ code at it, and it would trace through the code paths and quickly find subtle bugs that would take a human forever to track down. It was also great at pinpointing things that would usually be Heisenbugs.

It ran every few days against our code base, and a nice feature was that we could tell it, "This isn't really a bug," and it would remember that in the future.

The gotcha is, Coverity is really expensive. They don't publish the costs, but I get the sense that for commercial projects, it starts in the hundreds of thousands of dollars per year. But it probably saved us having to hire a whole bunch of developers and QA staff, so on the whole our management seemed to think it was a good buy.

Having had that experience, I look quite favorably on static code analysis.

Anything that is a measurable, well-defined pattern can be parsed.

A deeper question is why would this be important (and important enough to measure and evaluate it with a tool)? How would you meaningfully 'score' or quantify the results, and how would you use those scores? The answer to those questions will tell you why there aren't many tools with that kind of capability, and the ones that are out there with a feature-set advertising this kind of capability are limited, either: pricey, fragile, or some blended combination of the two.

In the past, at least six or eight years ago, I saw these features in the upper end editions of UML tools, like Rational and Sparx Systems (architect/enterprise oriented editions of each respective version). From what I can remember, these products could sometimes 'see' EAA patterns in models of imported/analyzed source. They would suggest complementing patterns and naming for other facets that were participating somehow. Or they would let you 'stub-in' skelatons of these patterns (somewhat useful, but counter to a degree in how patterns are supposed to more often than not, organically emerge).

Identifying patterns of any kind was a very new concept at the time, and in one of the first sets of tools that would incorporate this kind of built-in feature, finding patterns of any kind, but also including EAA patterns. I haven't really looked at them since, so perhaps they are now more refined, stable, and economically feasible.

Perhaps they are also available from someone where the tools operate directly on source (instead of a model), but I am not aware of it.