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:

a good rule that will contribute to program quality and programming productivity?
an unnecessary neutral rule that will have little effect one way or another?
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 article¹ 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:

Some of the standards reflect good practice and deserve a place in an organization's methodology
Some of them indicate naïveté or lack of knowledge of programming.
A few of them may lead to programs that are more complicated, harder to maintain, or less reliable.
All of them reflect an old-fashioned, inflexible, military style, in which the professional staff is neither encouraged to participate in establishing the organization's methodology nor trusted to use sound judgment in applying it.

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 strcat² on any character string that originated from a source outside the program's direct control.

So, 10 isn't so magic, after all.

¹ -- Gerard J. Holzmann: "The Power of 10: Rules for Developing Safety-Critical Code", IEEE Computer, June, 2006, pp. 95-97.

² -- 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.