4. Structuring the Code

4.1. Method Complexity

Keep methods short. As a general rule, if a method does not roughly fit into an editor window, you should probably split it up into smaller methods.

The primary exception to this rule is a large switch with a long list of case statements inside.

Keep nesting levels shallow. Blocks nested more deeply than about 3 levels usually make the code hard to understand. Again, you can solve this by moving inner blocks into separate methods.

4.2. Modularity

Restrict access to information to a minimum:

  • Restrict the scope and visibility of each variable as much as possible. In C and C++, use const wherever applicable.

  • Avoid global variables and functions. Where you cannot avoid them (e.g., in C), restrict their scope to the compilation unit using static wherever possible.

  • Organize your code into reasonably small compilation units.

  • In object-oriented programs, carefully choose the right protection level for each class and each of its members.

  • In C and C++, use the const keyword wherever possible.

4.3. Clarity and Robustness of Code

Stick to standards to ensure maximal portability of your code.

  • If possible, configure your compiler to only accept standard-compliant code. (For the Gnu Compiler Collection, use the compiler command-line options --std=c99 --pedantic. Be careful though – this does not necessarily reject extensions conforming to newer standards; see the next point.)

  • Before using any particular construct or library function, be sure that its use is covered by your chosen standard(s).

  • Rely only on documented, standard behavior. Never try out how a method or programming construct behaves in borderline cases. The behavior you observe may be different on another system, or tomorrow on your system.[2]

  • If you find that you must use a non-standard method (e.g., provided by your specific programming environment or software library), then separate standard from non-standard code as cleanly as possible to facilitate a replacement of the non-standard parts at a later time.

Avoid questionable or irritating constructs. Do not write

if (a = b)

even if it is correct in your situation.

In switch statements, account for all possible cases (e.g. by including a default), and signal an error if an impossible situation occurs. In general, try to catch seemingly impossible situations so you can diagnose problems later. Do not assume that such situations will not occur.

In general, always compile your code with all reasonably avoidable warnings turned on (compiler command-line options -Wall -W for the Gnu Compiler Collection), and make sure your code compiles without any warnings at all.

If your programming language allows it, declare variables close to their first use. Also, stick to the general rule

One variable for one purpose.

Do not reuse variables for other purposes, unless their purpose is trivial (such as loop counters named i). It makes code much easier to understand. Moreover, the compiler's optimizer does a much better job at eliminating redundancies than you do.

[2] This is an extremely important point. Failure to observe it has led, among others, to the current abundance of faulty Web pages containing non-standard HTML and JavaScript code that rely on specific bugs in Microsoft's Internet Explorer, instead of pressuring Microsoft to fix their code. Always fix problems at the root!