I will start by making an assertion that will annoy some people: the quality of much commercial coding is a disgrace.

Over more than thirty years, I have seen code, running critical services on production systems, which relies on the knowledge held by the original programmers for maintenance. When those individuals leave the organisation, the code becomes un-maintainable, often at a huge cost to the organisation. Worse still, these programmers, while still within the organisation, actively resist efforts to alleviate the problem. Although it is human nature to resist change, often in the belief that the change is a threat to job security, it represents a major hazard to the organisations using these applications.

What follows, then, is intended to prevent the situation arising and provide a plan to rectify the situation if it already present.

Basic Standards

These are the most basic requirements to which all source code must conform, if it is to be considered of production standard:

  • Use informative variable names (again, discussed in Documentation)
  • Maintain a proper change history

Preventing Bad Code

Management must accept the challenge of providing proper standards, which all code must meet and policing those standards. It was common, forty years ago, for managers to admit their ignorance of programming. It should not be acceptable in the 21st century for any manager, who is responsible for IT systems, to make such an admission.

That is not to say that managers are expected to be programmers or even IT professionals. They must, however, possess a clear understanding of what their organisation requires of critical systems and if necessary, call in outside help, to ensure that those requirements are being met.

Forbidden Things

The following is a list of things that coders should not do, while accepting that, sometimes, rules may be broken for good reasons…

  • Use the same variable name inside a sub-segment as is used outside of it.
  • Reuse the same variable name for two different purposes, even if in separate segments.
  • Change pointer variables into other types, while retaining the same name, for any reason.
  • Use floating point numbers in loop control statements.
  • Hide processing inside loop control statements.
  • Use multiple pointers to one object.
  • Fail to end a test with a default value or operation.
Last modified: 2012/12/18 12:50