Development Qualities: Readability > Duplication > Performance
Product Qualities: Usability > Redundancy > Performance
- Code is as much a product to developers and the product itself is to users.
- Always true unless it will be discarded immediately.
- If you can't explain it you can't do it right.
- If someone else can't understand it then they can use it. (Could be yourself in a few months.)
- If the code has to be optimized heavily for performance then that optimized code needs to be written especially better so it can be easily understood and it must say what optimizations have been implemented and why.
- Redundancy and duplication can be a good thing is it improves overall usability and readability. I say overall because you have to judge the specific case against the added complexity.
Use smart objects and dumb code.
- Related to don't repeat yourself principle.
- Just remember how fun it is to read code you're not familiar with, and how long it takes.
- Few people even remember their own code after a while.
- The code should be descriptive and make it very clear what is happening, but code itself cannot explain why it is needed.
- It's better to write easy to understand code and optimize if later if possible.
- Optimization is not possible without profiling.
- It is okay to do simple obvious optimization when it doesn't hurt readability.
Trust, but verify.
- A Russian proverb made famous by in the west by Ronald Reagan concerning nuclear disarmament.
- A belief without evidence is not sufficient for knowledge.
- For programming it means testing.
- For requirement gathering it mean include features in plans but check if necessary before implementation.
- For people "It's not that I don't believe you, it's that I need to know you're right."
- Closely related to the cover your ass principle.
- Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
- LeBlanc's Law
- Technical debt
- Addressing problems as they are found and fixing them properly results in higher efficiency and higher quality.
- Quick fixes are the same as doing it later but often worse.
- Maximizing output maximizes output required (effort, time, and cost).
- It is easy to put something off, difficult to do it now, and nearly impossible to start doing something that has been put off.
- Slow and steady wins the race.
- It takes more time to read bad code then to clean it up.
- No jumps in logic.
- Set things up then resolve them.
The first rule of functions is that they should be small.
- This include length and width. Try to minimize the area not including blank lines.
- A lot of nesting results in triangle code.
Don't write in triangles.
- Nesting of code blocks results in triangle shaped code.
- This usually results in logical jumps when a long if block is followed by a short else block.
- This indents a lot of code making the code bigger and more difficult to read.