There are several ways in which you can ensure that your code is
extensible and flexible.
First, make your programs modular, with good interfaces between
the separate elements. Remember to focus on core functionality, not
extras. Adopt a defensive programming approach to algorithm design:
for example, when dealing with a number of possible options, always
include a code section to catch the ‘none of the above’ choice.
Good housekeeping will also help: tidy up by closing connections to
files, processes or databases just as soon as they are no longer needed,
actually check that everything is okay rather than assuming what
you’ve done has worked, and report problems – and progress – appro-
priately to those who need to know.
At the coding level, there are several things you can do to make your
programs both robust and adaptable.
Use concise but descriptive variable names, and use variables rather
than hard-coded values. Put in helpful comments. Be clear, not obscure,
and make your code easy to read. Don’t over-optimize, or use platform-
specific tweaks.
Remember: if it can go wrong, it will, and if it can’t go wrong, it
probably still will. Build gradually. Know what you are supposed to be
doing, and don’t write unnecessary code.
Keeping track of what you are doing
One thing you will need to consider is what might be called ‘the admin-
istration of development’.
Obviously, you should try and upwardly delegate all the more brain-
numbing tasks, but it is likely that you will still need some way of
keeping track of (for instance) which is the latest version of the
program, which is the most solid, and which one contains that great
new feature but keeps unexpectedly crashing.
Applications to do this job go by various names, but their common-
core purpose is to allow you to keep track of which program version
currently works best.
Depending largely on your working environment, you may want
to consider full source control and code management systems, a
handmade version-numbering control method, ways that you could
roll back to previous versions, and alternative techniques for
identifying the functionality associated with particular stages of code
development.
84 CODING STYLE