Automatic Source Code Review is Development Tools Next Frontier

 
 
By Peter Coffee  |  Posted 2005-06-06 Email Print this article Print
 
 
 
 
 
 
 

Case Study: Coding standards should leave room for innovation.

Automatic source code review—comparing a programmers work against a growing library of coding standards—is the new frontier of development tool sets. Integrating both general and task-specific rules of readability, reliability and security into the coding process is becoming a top priority of those responsible for equipping development teams.

Convenient means of customizing and extending those rule bases should also be on the list of criteria applied by those who make an organizations tool-buying decisions. Clear and consistent support for those standards—throughout the development life cycle—is the larger goal that managers should strive to attain.

A limited form of software standard checking is performed every time a developer runs the tool chain that converts human-readable source code into machine-executable form. That minimal check, however, merely asks, in effect, "Is there at least one valid program that corresponds to this sequence of symbols?" An affirmative answer isnt enough to earn admission into the trusted code base at any organization that relies on software for critical functions—especially as enterprise applications are required to satisfy a lengthening list of stakeholders and other interested parties .

A valid program can still be vulnerable to common attacks, or subject to misinterpretation by a future maintenance programmer, or likely to stumble over a weakness in the programming language or its run-time environment. Increasingly, developers and especially large development teams are therefore codifying larger and richer bodies of knowledge and practice in ways that permit rapid and accurate verification by automated tools.

One current effort that offers informative guidance to software tool buyers is the SAMATE (Software Assurance Metrics and Tool Evaluation) project at the National Institute of Standards and Technology. The engineers involved in SAMATE released a project plan in May that considers possible application of tools at several stages of a software project, beginning at requirements capture and extending through post-deployment end-to-end scanning for possible vulnerabilities.

At the heart of the resulting SAMATE taxonomy is the life-cycle stage labeled "assessment, auditing, and acceptance," where automated code scanning and code review aids can be brought to bear. The project site lists a number of source code scanning tools that address different levels of standards compliance. The identified products, some proprietary and some open source, run the gamut from the narrowly focused task of preventing out-of-bounds array access in C++ programs to much broader policy enforcement tools such as those from Parasoft, Fortify Software and Programming Research Group.

To get a sense of what it means to promote higher software quality by verifying compliance with coding standards, a developer can browse a document such as Programming Research Groups "High-Integrity C++ Coding Standard Manual". Its suggested strictures prohibit the use of poorly defined portions of the language, language features often used incorrectly by programmers and parts of the language known to be affected by errors in some compilers.

Click here to read about SOA development standards. To understand the reasons for the Programming Research rules, such as "Do not overload or hide inherited non-virtual functions," is to understand more fully the inner workings of C++. It is also a persuasive indoctrination against being too clever in exploiting C++ mechanisms. A manager with specific knowledge of local tool weaknesses or particular customer requirements might further restrict a teams use of a general-purpose development language to avoid likely problems.

At the same time, though, a development manager will do well to remember the admonition of Perl programming guru Teodor Zlatanov in his 2001 book, "The Road to Better Programming." Comparing the project leader to the orchestral conductor, Zlatanov warns that "a programmer shouldnt be required to follow precise code guidelines to the letter; nor should he improvise those guidelines to get the job done. Consider an orchestra: neither static, soulless performers nor wildly improvisational virtuosos. The conductor creates harmony."

Coding standards, and the tools that apply them, should leave room for craftsmanship without inviting chaos.

Technology Editor Peter Coffee can be reached at peter_coffee@ziffdavis.com.

Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.
 
 
 
 
Peter Coffee is Director of Platform Research at salesforce.com, where he serves as a liaison with the developer community to define the opportunity and clarify developers' technical requirements on the company's evolving Apex Platform. Peter previously spent 18 years with eWEEK (formerly PC Week), the national news magazine of enterprise technology practice, where he reviewed software development tools and methods and wrote regular columns on emerging technologies and professional community issues.Before he began writing full-time in 1989, Peter spent eleven years in technical and management positions at Exxon and The Aerospace Corporation, including management of the latter company's first desktop computing planning team and applied research in applications of artificial intelligence techniques. He holds an engineering degree from MIT and an MBA from Pepperdine University, he has held teaching appointments in computer science, business analytics and information systems management at Pepperdine, UCLA, and Chapman College.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Thanks for your registration, follow us on our social networks to keep up-to-date
Rocket Fuel