These are the rules from The Elements of Programming Style by Brian W. Kernighan and P. J. Plauger. They haven’t steered me wrong yet and most remain as relevant today as they were when they were first published.

1. 10.0 times 0.1 is hardly ever 1.0.
2. Avoid ELSE GOTO and ELSE RETURN.archaic
3. Avoid multiple exits from loops.
4. Avoid temporary variables.
5. Avoid the Fortran arithmetic IF.archaic
6. Avoid THEN-IF and null ELSE.
7. Avoid unnecessary branches.
8. Choose a data representation that makes the program simple.
9. Choose variable names that won't be confused.
10. Document your data layouts.
11. Don't comment bad code – rewrite it.
12. Don't compare floating point numbers solely for equality.
13. Don't diddle code to make it faster – find a better algorithm.
14. Don't just echo the code with comments – make every comment count.
15. Don't over-comment.
16. Don't patch bad code – rewrite it.
17. Don't sacrifice clarity for small gains in efficiency.
18. Don't stop at one bug.
19. Don't stop with your first draft.
20. Don't strain to re-use code; reorganize instead.
21. Don't use conditional branches as a substitute for a logical expression.
22. Each module should do one thing well.
23. Follow each decision as closely as possible with its associated action.
24. Format a program to help the reader understand it.
25. Identify bad input; recover if possible.
26. Indent to show the logical structure of a program.
27. Initialize constants with DATA statements or INITIAL attributes; initialize variables with executable code.archaic
28. Instrument your programs. Measure before making efficiency changes.
29. Keep it right when you make it faster.
30. Keep it simple to make it faster.
31. Let the data structure the program.
32. Let the machine do the dirty work.
33. Let your compiler do the simple optimizations.
34. Localize input and output in subroutines.
35. Make input easy to prepare and output self-explanatory.
36. Make input easy to proofread.
37. Make it clear before you make it faster.
38. Make it right before you make it faster.
39. Make sure all variables are initialized before use.
40. Make sure comments and code agree.
41. Make sure every module hides something.
42. Make sure input cannot violate the limits of the program.
43. Make sure special cases are truly special.
44. Make sure your code does nothing gracefully.
45. Make the coupling between modules visible.
46. Make your programs read from top to bottom.
47. Modularize. Use procedures and functions.
48. Parenthesize to avoid ambiguity.
49. Program defensively
50. Replace repetitive expressions by calls to common functions.
51. Say what you mean, simply and directly
52. Take care to branch the right way on equality.
53. Terminate input by end-of-file marker, not by count.
54. Test input for validity and plausibility.
55. Test programs at their boundary values.
56. Treat end of file conditions in a uniform manner.
57. Use data arrays to avoid repetitive control sequences.
58. Use debugging compilers.
59. Use DO and DO-WHILE to emphasize the presence of loops.
60. Use DO-END and indenting to delimit groups of statements.
61. Use free-form input when possible.
62. Use IF ... ELSE IF ... ELSE IF ... ELSE ... to implement multi-way branches.
63. Use IF-ELSE to emphasize that only one of two actions is to be performed.
64. Use library functions.
65. Use recursive procedures for recursively-defined data structures.
66. Use self-identifying input. Allow defaults. Echo both on output.
67. Use statement labels that mean something.
68. Use the fundamental control flow constructs.
69. Use the good features of a language; avoid the bad ones.
70. Use the telephone test for readability.
71. Use uniform input formats.
72. Use variable names that mean something.
73. Watch out for off-by-one errors.
74. Write and test a big program in small pieces.
75. Write clearly – don't be too clever
76. Write clearly – don't sacrifice clarity for efficiency.
77. Write first in an easy-to-understand pseudo-language; then translate into whatever language you have to use.