Thursday, 13 November 2014

Programming Aphorisms

There are some simple saying that I like that help me write better code. They may not be true in all cases but are generally true. I'll probably update this over time.

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.
Programs must be written for people to read, and only incidentally for machines to execute.
  • 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.
Code tells you how; comments tell you why.
  • The code should be descriptive and make it very clear what is happening, but code itself cannot explain why it is needed.
Premature optimization is the root of all evil.
  • 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.
If you don't know how to do something, you don't know how to do it on a computer.

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.
Don't repeat yourself.
  • Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
Later equals never.
  • 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.
 The only way to go fast -- is to keep the code as clean as possible at all times.
  • Slow and steady wins the race.
  • It takes more time to read bad code then to clean it up.
Master programmers think of systems as stories to be told rather than programs to be written.
  • 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.