Write clearly
Don't be clever
Don't branch around branches
Say what you mean, simply and directly
Library functions are one way to reduce the apparent complexity of a program
Use library functions
Avoid temporary variables
Write clearly, don't sacrifice clarity for 'efficiency'
Replace reptitive expressions by calls to a common function
Parenthesize to avoid ambiguity
Choose variable names that won't be confused and mean something
Use the telephone test for readability
Write your own library functions if they do not exist and be sufficiently general that your routine can be used in future applications and by other people
Make sure conditional test read clearly by reading them aloud
Use spaces and indenting to delimit groups of statements
Make your programs read from top to bottom
Write first an easy-to-understand pseudo-language; then translate into whatever language you have to use
After you make a decision, do something
Follow each decision as closely as possible with its associated action
Use data arrays to avoid repetitive control sequences
Often you must write a preliminary draft of the code before you can determine what changes tin the data structure will simplify control
How can I organize the data so the computations becomes as easy as possible?
Choose a data representation that makes the program simple
Write it clearly so it works; then check later whether it's worth your while to rewrite parts of it
No program is ever perfect; there is always room for improvement
Don't stop with your first draft
Plan your data structures with the same care that you use for the control flow. Try to find a data representation that leads to a simpler program
Optimizing too early in the life of a program can kill its chances for growth
Well designed building block are often usable in other applications, contributing to a library of larborsaving routines
Make the coupling between modules visible
Combining too many functions in one module is a sure way to limit its usefulness, while at the same time making it more complex and harder to maintain
Each module should do one thing well
Make sure every module hides something
Let the data structure the program
Don't patch bad code
Rewrite it
Write and test a big program in small pieces
The only way to write and maintain a big program is as a set of small functions, subroutines, or procedures. No module should have to know much about the total problem, nor deal with more than a handful of immeditate neighbors
Never trust any data
Test input for validity and plausibility
Make sure input cannot violate the limits of the program
Identify bad input; recover if possible
Make input easy to prepare and output self-explanatory
Use uniform input formats
Make input easy to proofread
Use free-form input when possible
Localize input and output in subroutines
Make sure the program structure reflects the data the program processes
Take care to branch the right way on equality
Make sure your code "does nothing" gracefully
Test programs at their boundary values
Make it right before you make it faster
Avoid multiple exits from a loop. Keep exit tests close together and as near the top as possible
Program defensively. Be aware of the kinds of things that could go wrong, and add code to check for them
Make it clear before you make it faster
Efficiency likewise depends strongly on data representation
Simplicity and clarity are often of more value than the microseconds possibly saved by clever coding
Don't sacrifice clarity for small gains in 'efficiency'
Don't strain to re-use code; reorganize instead
Make sure special cases are truly special
Keep it simple to make it faster
Don't diddle code to make it faster
find a better algorithm
Instrument your programs. Measure before making "efficiency" changes
Make sure comments and code agree
Don't comment bad code
Rewrite it
Use variable names that mean something
Format a program to help the reader understand it
Indent to show the logical structure of a program
Document your data layouts