Coding & Development Conventions - An Essay

By: Richard G. Russell - www.io.com/~richardr

June 2000

The Value of Coding and Development Conventions

Very often, coding conventions, and even worse - coding standards, really chafe on software developers. They are often seen as bureaucratic nonsense that gets in they way of just-writing-it. Rigid standards created to satisfy management's desire for 'control' can stifle creativity... Even worse; blind, or forced, adherence to rules can cause program quality to suffer. For example, not allowing the use of 'break' or 'continue' in C or C++ can result in some really ugly hack. This is unfortunate, because conventions can be one of the most powerful tools in a software engineer's tool box.

Conventions have several benefits:

They let the programmer take more for granted. By making one global decision rather than many local ones, programmers can concentrate on more important tasks.
They let programmers transfer knowledge and information across projects. If there is a conventional way of doing something, it is more likely to be beneficial in a future or concurrent project. This could be as simple as saying ‘gee that worked pretty good there, lets try it here’. In the best case, will written code can be plucked from one project and used in another as is. Doing things differently from programmer to programmer, or from project to project makes this much more difficult.
Conventions really help programmers that are unfamiliar with a system or project come up to speed much more quickly. With conventions, the reader can study a consistent set of code; rather than learning the way Bob programs, and the way Susan programs. Good conventions also help a new person understand common idioms, even those that are not strictly part of the code such as directory structures, where to find things on the network, how the organization uses version control, etc. etc.
A good set of software development conventions are the genetic pool of a world class software organization. Good conventions are the result of consensus (more or less) of a group of people and evolve as time goes along. Things that don’t work are discarded, things that work are improved. This isn’t to say that conventions should be designed purely by committee, but that the synthesis of ideas from several people over a period of time is usually a good thing.
Conventions encourage and facilitate code evolution. What is evolution…? …it is building upon the work of the previous guy. Evolution is not really code reuse, although this is an important component, but more like building a pyramid, layer on layer, earlier work supports later work.
Conventions help programmers from repeating bad history. While its obviously important to write good code. Its just as important not to write ‘bad’ code. Some stuff is obvious, but other things are not; some things are very arcane and are dependent on the corporate culture, knowledge of undocumented legacy systems, unique individual knowledge, and special or assumed requirements. Good conventions can help document this or make it more clear.
Conventions can do great things to encourage and facilitate portability. This is really important when working with multiple operating systems or target processors.
Conventions help the programmer really think about what he or she is doing. To often, we have the urge to just-code-it. Unless you are lucky, a quick hack will usually come back to haunt you. Sticking to conventions help you do things right the first time, instead of hacking it the first time, and doing it right the second time. Or worse, patching a hack.