Strive for elegant simplicity; software should be as simple
as possible, but not simplistic.
Code should be written more for readability and less for the
convenience of the person writing it (it will be read many more
times than it will be written). Readability means clarity,
simplicity and brevity.
One should say what one means in code, as simply and directly
as possible.
Corollary: lots of indirection or overuse of macros to hide
details is neither simple nor direct. That's an optimization for
the writer, not the reader; see (2).
One should not optimize code unless it can be shown that it's
actually a performance bottleneck in a measurable way. Favor
simplicity over performance until one has numbers that show that
performance along some important dimension is actually an issue.
Prefer a single, simple solution that's portable over many
solutions that are optimally performant. The compiler will probably
catch up eventually anyway.
Where one must optimize, measure twice before doing so and
make sure one understands the results. Make sure the measurement is
sound and the statistical method valid. Optimize only the slow part
of the program. Mark optimized parts clearly; they're often an area
for cleanup as compilers catch up or the environment otherwise
changes.
Look for algorithmic changes or different data structures to
improve performance before twiddling bits.
A simpler program is often easier to optimize at a high level
(e.g., using a more appropriate data structure instead of optimizing
instructions).
Corollary: premature optimization is often a pessimization.
Cache locality, alignment, and other such things can have
outsized effects. Beware just reading code: one needs an appropriate
benchmark that measures the code executing in context to
understand performance.
Avoid undefined behavior. It will come back to bite you: