- If it ain't broke, don't fix it.
- Design for failure.
Can also be expressed as "shit happens so plan for it and deal with it".
- Verify your assumptions.
- Implementation matters.
- Interfaces matter more.
- That which works is better than that which doesn't.
- Elegance matters.
- Cuteness doesn't.
- If it hasn't been tested then it doesn't work.
- Solve the right problem.
- Understand when performance matters.
- Correctness always matters (i.e. nobody is interested in fast wrong answers).
- Explain why.
- Flexibility matters.
- True perfection is more often achieved by removing features than by adding features.
Can also be expressed as "avoid feeping creaturism".
- Code for the ages (i.e. pretend that YOU are going to have to maintain the code in five years).
- Avoid magic numbers.
- Think ahead. No! Further than that!!
- If it ain't broke, don't fix it.
'nuf said.*
Sources
- twenty plus years of making mistakes with a computer keyboard.
* Many of these could use clarification and/or elaboration.
I and/or others will/should/have/might write nodes (or even entire books) as appropriate.
I don't believe that adding dozens of paragraphs of clarification in this writeup would be appropriate (and it would take dozens of paragraphs to clarify/elaborate all of these "laws" properly).