C Language

How Big Is the World?

As a C programmer, project leader, or manager, you can't control the whole world of C programming. So what's a reasonable domain to concentrate on? Single programs, and even projects, are too narrow in scope. If a programmer has to learn new styles, techniques, and tools when he or she moves among programs or projects, the benefits of knowledge and code reuse are small. On the other hand, for most important C and C++ programming issues, there are no industry-wide standards. The various standards for lexical style (e.g., "K&R") are only a minor aspect of C/C++ programming standards and, in many cases, are simply not very good.

The target to shoot for is company- or site-wide standards. Based on the size and geographical distribution of the programming staff, try to cover a domain that meets two criteria:

* A person covered by the standards has a reasonable opportunity to participate in the development and revision of the standards.
* A person who continues to work for the organization is likely to remain within the domain covered by the standards (i.e., in most cases, if they change assignments, they'll still follow the same standards).

As you develop standards, keep in mind that nobody can include in written standards a rule to cover every situation a programmer will encounter. There's no way to turn C or C++ programming into a mechanical task. Standards should record a sensible set of guidelines so programmers can use consistent styles and techniques - standards aren't laws.

Here's an example that involves indenting. On PCs, it's convenient to set eight-character tab-stop intervals (i.e., 9, 17, 25, etc.) because the MS-DOS TYPE and PRINT commands, and many tools, use this default. Consequently, adopting the same interval for indenting in C programs is a reasonable standard. In some cases, however, a section of a program may have enough levels of nesting that statements begin very far to the right when displayed by an editor or when printed. As a result, statements may either need to be "chopped" up and continued across multiple lines, or they will be inconvenient to display or print.

The best solution to this occasional problem is neither chopping up lines nor changing the overall indenting standard to a smaller interval. Instead, a programmer can simply use a different indent interval, say four characters, for just the deeply nested section of code. This may involve a little more editing effort for those statements indented to a level not an even multiple of eight characters (although with good editors, this is quite easy to do), but the code remains readable when displayed or printed and the convenience of the eight-character interval (in the MS-DOS environment) is retained.

This example illustrates how "master" programmers approach standards. They focus on the underlying principles, of which consistency is a very important one. But consistency should apply to the principles, not just simplistic rules. Here the principles underlying the choice of an eight-character indentation interval were to produce a readable layout and to allow convenient manipulation (with the editor and other tools). There's nothing sacred about an eight-character interval, however, and there may be circumstances where using some other size better serves the underlying principles.