It's important to keep in mind that there are vast differences in static analysis tools. Some of the commercial ones that John mentions in the post are quite powerful but also very expensive and out of reach for most startups / smaller companies. Most of these started off as spin-offs from research groups, and there's hundreds of man-years of research behind some of them, which (IMHO) makes the technology hard to replicate in the open-source world.<p>Then there's open-source static analysis tools, which unfortunately are often much less powerful. Especially for dynamically typed scripting languages like Python it's very difficult writing good static analyzers because there's no type information available (projects like mypy should improve that though). In my opinion, when working with such languages gradual typing like done by MyPy / type annotations in Python or transpilation like Typescript does is a very good first investment when developing in these languages, and will also make static analysis easier later.<p>There are some studies (I can't find the link now) that compared various measures for improving code quality in terms of cost and effectiveness, and the takeaway was that if you're starting out with QA manual code reviews are usually the most cost-effective way to improve software quality. Of course you will need to invest some time in getting a high-quality review process set up, and ensure that there are developers in your team that have the experience to do meaningful reviews.
Here is a good serie of articles on static analysis tools : <a href="http://btorpey.github.io/blog/categories/static-analysis/" rel="nofollow">http://btorpey.github.io/blog/categories/static-analysis/</a>
Two others worth checking out that focus on soundness with low to no false positives are RV-Match and TrustinSoft Analyzer:<p><a href="https://runtimeverification.com/match/" rel="nofollow">https://runtimeverification.com/match/</a><p><a href="https://trust-in-soft.com/products/" rel="nofollow">https://trust-in-soft.com/products/</a><p>The RTV people are the one's behind K framework and an executable semantics for C with a GCC-like interface:<p><a href="http://www.kframework.org/index.php/Main_Page" rel="nofollow">http://www.kframework.org/index.php/Main_Page</a><p><a href="https://github.com/kframework/c-semantics" rel="nofollow">https://github.com/kframework/c-semantics</a><p>That RV-Match builds on an open framework, does well on benchmarks (yeah skepticism here), and has little to no noise (most important) is what I like most about it. I say most important since digging through false positives makes developers not want to use a tool. I haven't tried either product myself, though.<p>Here's a list of open tools that did well in small-scale experiments with and without false positives:<p><a href="https://klee.github.io" rel="nofollow">https://klee.github.io</a><p><a href="http://www.cprover.org/cbmc/" rel="nofollow">http://www.cprover.org/cbmc/</a><p><a href="https://cseweb.ucsd.edu/~rjhala/blast.html" rel="nofollow">https://cseweb.ucsd.edu/~rjhala/blast.html</a><p><a href="http://www.splint.org" rel="nofollow">http://www.splint.org</a><p><a href="http://spinroot.com/uno/" rel="nofollow">http://spinroot.com/uno/</a><p><a href="http://cppcheck.sourceforge.net/#features" rel="nofollow">http://cppcheck.sourceforge.net/#features</a><p><a href="https://en.wikipedia.org/wiki/Sparse" rel="nofollow">https://en.wikipedia.org/wiki/Sparse</a><p><a href="https://cpachecker.sosy-lab.org" rel="nofollow">https://cpachecker.sosy-lab.org</a>
Paraphrasing Dijkstra: “Using static code analysis shows the presence, not the absence of bugs.”<p>See: (1) “Finding Heartbleed with CodeSonar”, (2) “Why Do Software Assurance Tools Have Problems Finding Bugs Like Heartbleed?”<p>[1] <a href="http://blogs.grammatech.com/finding-heartbleed-with-codesonar" rel="nofollow">http://blogs.grammatech.com/finding-heartbleed-with-codesona...</a><p>[2] <a href="https://www.swampinabox.org/doc/SWAMP-WP003-Heartbleed.pdf" rel="nofollow">https://www.swampinabox.org/doc/SWAMP-WP003-Heartbleed.pdf</a>