Content area
Full Text
Software can get sick, according to the author, and should be inoculated This article offers several rules to increase the quality of the software product by helping developers define a verifiable and enforceable defensive programming standard for their software development teams,
Software professionals have learned over the years that software is prone to illness. I use the term "illness" instead of "software error" or "failure" because software inherently doesn't fail. Given the same operating conditions, the software will behave in a predictable manner. The behavior may not be desirable and may induce a failure in the overall system but the software itself does not fail. Contrast that with a failure in a mechanical system due to fatigue. The software may have been coded incorrectly or coded correctly to an incorrect requirements specification. The symptom of the illness can be partial or complete system failure and is often hidden for most operating conditions. After the software has undergone verification and validation, it is considered healthy and ready to be released to the public. All too often it is only when the product is in the hands of the customer that the symptom of the illness becomes evident.
Neither is the compiler immune to symptomatic illness, since it is a complex software system. Initially, C compilers on the market had characteristics that were often unique to themselves. After all, compiler writers had no common standard that fully defined their product's operation. Even when a programming standard was defined by the C standards committee, some compiler writers, particularly those for embedded systems, continued to treat the standard as the committee's opinion of how their product should behave. What amplities this problem is that the committee defining the standard could not even agree on some of the behaviors of the C programming language (for example, Annex G ISO/IEC 9899-1990 unspecified behavior).'
The intent of this article is to increase the quality of the software product by defining a verifiable and enforceable defensive programming standard for your software development team. This standard should take into consideration the limitations of the C coding standard and your compiler. Develop a habit of using defensive programming techniques.
What's a software professional to do in this complex world of compilers, committees, and...