This post originated from an RSS feed registered with Perl Buzz by Andy Lester. Original Post: To InformationWeek re: static code analysis Feed Title: Perlbuzz Feed URL: http://perlbuzz.com/atom.xml Feed Description: What's happening in the world of Perl programming, including Perl 5, Perl 6, the CPAN and Parrot? Latest Perl Buzz Posts Latest Perl Buzz Posts by Andy Lester Latest Posts From Perlbuzz

Sent to editor of DrDobbs/InformationWeek

I enjoy Sid Sidner's article on static code analysis tools, but was surprised to see two big omissions, especially as they may provide a low-cost point of entry to the organization just starting to look at static analysis.

First, PC-Lint is a relatively low-cost tool that does a fine job of C/C++ analysis. It's been around for years, and has found many C bugs in my code back in the early 90s. I've also been using the open source Splint, for years on the Perl 5 and Parrot open source projects. Although Splint's not nearly as complete a package as Coverity's Scan product (Coverity runs Scan on dozens of open source projects for free as a service to the community), it's a great introduction to the power of static code analysis tools. I also suggest readers check the "List of tools for static code analysis" page on Wikipedia.

Second, one crucial point missed is how any tool is going to require tuning. Splint will generate hundreds of errors in each source file on its first run on your code, since nobody in the real world is as pedantic as the tool is. Each organization will have to decide which policies are worth following, and which are just noise.

Finally, static code analysis isn't strictly for C++ and Java. Many dynamic languages have similar tools. For example, Perl::Critic is a fantastic tool for analysis of Perl code, as well as an extensible framework that lets each organization create custom policies to fit its own development practices.