by Conrad Weisert, June, 2006
Six years ago I posed a list of eight COBOL programming techniques that I had found in the in-house programming standards manuals of actual application development organizations. I asked readers to assess whether each one was:
That conclusion surprised people who knew me as a strong supporter of programming standards, but it shouldn't have. Nothing damages the cause of enlightened methodology more than standards that are silly. unnecessary, arbitrary, bureaucratic, unenforceable, or unreasonably burdensome.
Now it's C's turn, but this time it's different. A recent article1 proposes some "safety critical coding rules" for C programs. The author claims that 10 is a magic number for such standards: If an organization has fewer than 10 discrete coding standards, he advises, dangerous practices will slip by, while if it has more than 10, the standards manual will be so thick and intimidating that no one will read it. If you're interested in C (or C++) programming, you can take a look at his proposed rules, and apply the same choices we offered for the COBOL standards. Or, I'll save you the trouble here:
In addition, if the author's main interest was safety (as opposed to maintainability or development cost), he overlooked what many believe to be the most important safety-related coding standard for C programmers:
Never use the standard C library functions
strcat2 on any character string that originated from a source outside the program's direct control.
So, 10 isn't so magic, after all.
1 -- Gerard J. Holzmann: "The Power of 10: Rules for Developing Safety-Critical Code", IEEE Computer, June, 2006, pp. 95-97.
2 -- In order to avoid the notorious buffer overflow bugs that have plagued Microsoft products, among others. A simple and fairly obvious coding standard avoids the danger while supporting the needed functionality.
Return to Technical articles
IDI home page
Last modified June, 2006.