Distinguishing between good and bad programming standards

Thoughts on Some Proposed C Coding Standards

by Conrad Weisert, June, 2006

Background -- a COBOL example

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:

  1. a good rule that will contribute to program quality and programming productivity?
  2. an unnecessary neutral rule that will have little effect one way or another?
  3. a bad rule that will do more harm than good?
and to give supporting reasons. Over a four-year span we got responses reflecting a broad range of opinion and experience. In the end, however, most contributors agreed that all eight proposed standards were unnecessarily burdensome, even harmful.

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.

Update -- an IEEE view

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:

I won't cite specific examples of each now, but may do so in the future in response to inquiries or opinions from readers.

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 strcpy or 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.