HOEKSTRA.CO.UK

A Collection of Coding Rules gathered over the years...

 

In the words of Suzi Quatrro, Wernher von Braun may have been "a fucking Nazi", but he had a point. How often have you not tested someting because there was a prevailing opinion of "what could possibly go wrong?", or "of course it will work!".

Testing Code

  • If it's not tested, it doesn't work.
  • If there is a bug, the user will find it.
  • A code review is not a criticism.
  • It's not the quantity of code that matters, it's the quality. Any idiot can bang out 40kloc (kilo-lines of code) but that doesn't make it fit for purpose.
  • Eat your own dog food — fixing bugs in your own code helps you code better and improves your understanding.

Egoless Programming

  • Just because you wrote it doesn't mean you own it — don't be offended if someone else on your team has to change your code.
    Don't reinvent the wheel, library code is there to help.
  • Just because you didn't write it doesn't mean it's crap.

Optimal Coding

  • The fastest code is code that's never executed — look for early outs.
  • Source code is just a hint to the compiler about what you want to do, it won't necessarily do it (e.g. You might declare a function as inline but the compiler doesn't have to obey).

Creating Maintainable Code


  • Code that's hard to understand is hard to maintain.
  • Code that's hard to maintain is next to useless.
  • The neater your code layout, the easier it is to read. The easier it is to read, the easier it is to understand and maintain.
  • Code is not self documenting. Help others by adding comments to guide them. You may understand it now but what about in 5 years time?
  • Magic numbers (i.e. hard-coded values in code) are bad.
  • Constants don't take up storage, they're compile time text substitutions.
  • The true cost of poorly written code is in the maintenance. 
  • Code rots over time.
  • Bad Code can and will come back to haunt you.


Delivery Planning

  • Project management will always want you to do twice as much in half the time.
  • There is no such thing as a 5 minute job. It'll always take at least half a day.
  • “Whilst I'm editing this file I’ll just…” is a great way to introduce feature creep and bugs.
  • If the user didn't ask for a feature, don't add it.


DevOps

  • Source control is your friend - make sure you use it.
  • Make sure you back up your work. Source Control is not the same as backing up.