Error Checking

One simple rule: do error checking. Modern computers are fast, no, they are very fast and a few lines of error checking isn't (generally) going to make a measurable difference to the straight line speed of an application. This is particularly true if the error checking that you are doing is just comparing numbers together - something a computer can do very quickly.

Depending on where you are in an application depends on how much error checking you should be doing. Any part of the application that interacts with the outside work should be 90% error checking and 10% useful code. The error checking is like armour plating for your application - the more it has the less likely it is to fall over in a big heap when the user enters some unexpected data (and uses enter unexpected data all the time).

If you have sufficient armour on the outside the heart of your application can be less armoured as you can be quite confident that the data you are receiving isn't going to cause any problems. You should still have some sanity checks to make sure that things are progressing as expected but hardcore error checking is probably best left to unit tests.

This technique of hardening the outside and leaving the inside to get on with computation produces reliable, fast and maintainable code. The simple rule to remember is: never trust anything that comes from the outside.

Optimization

If there is one thing guaranteed to break an application it is optimization. Never optimize an application unless there is a compelling reason to optimize it. Before even considering optimization ask this simple question: could I just buy faster hardware to overcome the problem?

Buying faster hardware seems like a rather extreme way of overcoming what is inherently a software issue but when you consider the amount of development and testing time a non-trivial optimization will take buying a faster machine to run the software on starts to look like a very cheap solution.

The problem with optimization is that it almost always makes code less readable and therefore less maintainable. Optimization also tempts developers to do things that are either unsafe or have unexplored consequences. In cases where optimization is often necessary, such as when developing real-time systems, first write code that completes the task correctly in any amount of time. Then develop tests against that code to produce a suite of tests that you know prove the correct outcome. Finally, optimize the code and continually run the tests against it to make sure nothing has been broken.

Before you even get started with ideas of optimization though you need to know what to part of the application optimize. Most developers think that they have an idea what part of their application is slow but the truth of the matter is that most of the time they are wrong. Optimizing the wrong bit of the application will have, at best, little to no effect and at worst break the application. Without using a profiler it is impossible to say for sure which parts of the application could do with some work.

It's difficult to tell which parts of an application are slow because a seemingly innocuous and assumed fast call that is made a million times might use up more time than something that is "obviously slow" that is only called just once. The "obviously slow" code could be optimized but the gains would be small compared to changing what appears to be the fastest code.

This section wouldn't be complete without repeating the statement made by the great man himself: "Premature optimization is the root of all evil." - Donald Knuth

<< How to Write Maintainable Code - Part 2