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.
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.
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!