Gluten meal on your lawn
Programming Research’s Structure101 module
There are many parallels between the use of organic fertilizer such as corn gluten meal (CGM) and code analysis tools for application development (Fig. 1). Both need to be used on a regular basis for the best results, while a one-time application rarely meets expectations.
The chemical competition tends to be bad for the environment and the grass in the long run, but CGM is all you need for most lawns. But while there are many code analysis tools, you can’t always get away with just choosing one. Sometimes, using more than one tool on the same project makes sense simply because of the kind of analysis that each performs.
Even a quick scan of the available options yields a long list, including Coverity’s Static Analysis, LDRA’s Tool Suite, Klockwork’s Insight, Grammatech’s CodeSonar, and Programming Research’s PRQA. Most target C, C++, and Java, which hits most languages used by embedded developers. There is even a number of open-source projects like Splint (see “Electronic Design Interviews U. of Virginia Computer Prof”) or CLang for Objective-C running on Apple’s Macintosh.
Static analysis can check for a range of problems, finding bugs before an application is even run. It can also enforce standards such as corporate coding standards like those set by organizations such as MISRA C. Additionally, these tools can check for security and safety issues.
These tool suites, especially the commercial ones, often address a range of code management and improvement tools. For example, LDRA’s Embed-X addresses life-cycle management. Programming Research’s Structure101, an adjunct to PQRA, displays the interaction within an application’s architecture (Fig. 2).
Is It Worth The Trouble?
The CGM answer is a bit easier. It isn’t toxic, so your dog and kids can play in the grass after it’s applied. It’s also good for the grass and environment, and it takes as much effort as using the alternatives.
For static analysis, the answer is just as easy but harder to accept by most programmers. It’s often harder to justify because it does take more work to use the tools, and commercial solutions often cost a good deal. This is especially true, as other components such as requirement analysis come into play.
Luckily, the use of more features may have more compile time overhead. But there are typically no additional development steps above the initial addition of a static analysis tool into the tool chain being used for development.
LDRA field application engineer Shan Bhattacharya agrees (see “Requirements Driven Development—Too Challenging To Be Worth It?”). So do many developers who use these tools on a daily basis.
Remember, the cost of finding and fixing bugs grows exponentially with respect to time as an application moves from the developer’s desktop to quality assurance (QA) to production to the field. Even finding a fraction of the bugs in an application using static analysis can provide payback well in excess of the cost of the tools.
And don’t forget other issues such as licensing. A number of companies such as Black Duck Software (see “Is It GPL If It Quacks Like A Duck?”) can help track the software, libraries, and platforms used to build an application to make sure you’re compliant with the requirements imposed by commercial and open-source licenses.
Time to mow the lawn. I only have to use CGM in the spring and the fall—a bit longer than most programming cycles. So how many of you use CGM and static analysis on a regular basis?