Most organizations today, and I would venture that all organizations involved in the production of high-integrity code use one or more development standards, in an attempt to improve the quality of the software produced. Among the common types of standards for development are Architecture Standards, Design Standards, and Coding Standards. Verification standards also exist, for the same reason. In this article, I will focus on coding standards, as that is where I have seen the bulk of issues.

As you may guess, I’m not the first to write on this topic, although I’ll admit that a Google search turned up rather sparse results for “how to * coding standard*”, still I did find this article. But I hope to go a little deeper here.

The principals may be generalized of software standards; but the examples and counter-examples will come primarily from my experiences with coding standards.  So, just what is my experience with these little gems?  Well, I’ve headed up creation or wholesale re-write of coding standards for a number of clients, and been a committee participant in several others, and as a long-time consultant have endured the existence of an untold number of others ranging from mediocre to awful. I’ve never actually been subject to one that I consider to be very good, even of those where I lead the development. One reason is that even a leader needs to get buy-in, if he’s not a dictator, let alone a permanent employee. When the disagreement is strong enough, you compromise. That’s just the way it is. But today is different. Today you are in my forum, and I get to do it my way.

I have a philosophy about coding standards. I call it the KISS principal. Bet you’ve never heard of that one, eh?  Well, it applies to coding standards in spades… Keep It Simple, Stupid!

One thing you must understand when creating a coding standard, is that every rule must be remembered by every developer.  A 30-page coding standard probably won’t be read thoroughly, much less remembered.  Most developers think they’ve got a pretty good handle on how things should be, so they pick-and-choose what they need to read, and if the meaning is muddled, they disregard. This is just my opinion, based on observation and lots of experience. Unless you plan to have a recurrent quarterly 3-day training session where every rule is explained clearly and justified, keep your standards short and concise.

Far too often, the codified standards reflect the preferences of a few people, or stodgy re-iterations of long-ago dictives for which there is no longer any justification. This stuff has got to go!

A note about DO-178B compliance: DO-178B does not require independent review that development standards were followed. That means it’s up to the programmer alone to determine whether he or she followed the rules. Even a top-notch programmer may misunderstand or forget rules, and if no one calls them on it, big messes can result. Some, probably most, of the rules in a development standard for a safety-critical environment exist to minimize the likelihood of unsafe or ambiguous behaviors. Any organization that does not require independent review of coding standard compliance is just asking for trouble, regardless of whether DO-178B, or any other process standard, requires it.

Now we get to the meat. What goes into a coding standard? How strictly should it be enforced?  How do we deal with exceptions? How is it organized? These are the standard questions (pun only slightly intended).  I’ve heard them over and over.  My answers are simple:

  • what goes in is only what must;
  • how it is organized, is for greatest accessibility;
  • enforcement is absolute; and
  • exceptions are handled by the structure.

Somehow, those responses just don’t seem to make it clear enough. The questions run too deep. There are too many ideas of what is necessary and what is not.

I find myself stating the same concerns, questions, points and counter-points, over and over. With this in mind, I have tried to define precisely what expectations I have for a coding standard. Some of my opinions are likely to be quite controversial, but I believe that they make for a cleaner, and more powerful standard. Create a rule against every bad programming construct you ever saw, and someone will invent a new one even worse. You can’t legislate good software. You can, on the other hand, endow review panels with the authority to mandate changes even where standards are not violated. In this way, you can be assured that not only were standards met; but the quality passed muster with the reviewers.

Without further adieu, I now present my meta-solution to the problem:

About Max H:
Max is a father, a husband, and a man of many interests. He is also a consulting software architect with over 3 decades experience in the design and implementation of complex software. View his Linked-In profile at