program will run, together with the conditions that are imposed by
local custom and practice.
Whatever tools you use, what is important is thinking about what
you need to do right now. If you think back to when you were learn-
ing to program, you used various techniques to help you fix your appli-
cations when they weren’t working. While bioinformatics software may
sometimes be more complex than that code, the same simple principles
apply.
Debugging starts before you code anything. For example, don’t write
code for which you cannot define success or failure, as you will never
know if it is doing what is needed; but the definition of success could
be analogue, rather than binary.
For instance, a requirement that ‘results must be accurate to within
0.02 per cent of target in at least 95 per cent of tests’, means that it
would be possible to begin writing this code and then work on opti-
mizing its functionality to the desired degree of accuracy.
However, with success defined as ‘100 per cent accuracy every time’,
or ‘right’, it would make sense to ensure this is provably achievable
before you begin implementation of any algorithm.
You need to know what should be happening, so that you can check
that it is happening. You may have a usable definition of success, but
to achieve that success you have to know what your code has to do,
and how – for example, retrieve relevant data from storage within a
specified time period under defined load conditions.
This means that before writing the code to perform this operation,
you need to think about how you could tell what it was doing. So, for
example, your code should tell you when it is about to make a con-
nection to the data store, as well as whether or not it succeeded.
This kind of coding can make it easier for you to see how your
program is running, and how far it got before it stopped, which helps
you to identify where in the code you need to start looking for the bug.
Remember, the more work you do now on preventing bugs creeping in
unnoticed, the less you have to do when they become apparent during
testing.
Some problems require the use of apparently more sophisticated
techniques than the use of print statements. Code checkers, whether
external, built-in, or supplied as optional language extensions, may
well be appropriate at various times, depending on the nature of your
application.
However, in this situation your development efforts will also be
greatly helped by tools that can, for example, tell you what the load
DEBUGGING TOOLS 43