Principle 4 Write Flexible Code

Write flexible code where it will save time later. Good code is often adapted and repurposed. However, don't try to solve every problem upfront, or try and cover edge cases you may never encounter. Find a balance and focus on making your code easy to change.

You Must - Break up your code into chunks, with a clear structure and don't repeat yourself.

You Should - Think about, and document the way your code might break with different inputs. Include input validation to catch mistakes earlier in your code and make it easier to repurpose.

You Could - Implement and test thorough error handling. Consider writing and sharing general purposes 'tool' code, especially if you solve a problem someone else might have.

Related Areas: Comments
Data Structure

4.1 Structure

Think about the structure and sequence of your code. Keep inputs and key parameters that might need to change in a separate section which is easy to find.

In some cases it may be appropriate to store such inputs in separate files which are read in, rather than storing them within the code.

4.2 Break up Your Code

You should look to break up your code into chunks rather than working in a single long script or program. Each chunk of code should have a clear purpose. You can then use call on these chunks of code to build your analysis.

There are many reasons to do this:

  • It's easier to see the structure of your code.
  • It's easier to make changes to your code.
  • It's easier to understand what has changed and what the effect is.
  • You only have to document each chunk once.

4.3 Don't Repeat Yourself

Don't Repeat Yourself is a common idea in programming. Instead of writing a bit of code several times to repeat an operation, you should re-use the same code by turning it into a function (or some other re-useable chunk - such as a method or subroutine).

4.4 Input Validation

Think carefully about the input required for your code to work correctly:

  • Data Type - Does the core require a specific class or type of input e.g. a number?
  • Range - Does the value of a variable need to be in a certain range, e.g. between 0 - 1?
  • Format - Does the code require the input to be in a particular format e.g. postcode?
  • Size - Does your code assume a particular size of input e.g. > 0 rows of data?
  • Allowed Values - Is there a whitelist of valid input values to check against e.g. months?

Building checks into your code for issues such as the above can make your code more robust. This will make it easier to repurpose with confidence in future.

You may want to consider adding error handling to handle what happens if what these checks aren't met.

4.5 Error Handling

Its likely your code will be asked to do something you didn't design it for, and it will break.

You do know however what your code should be doing, what the input is expected to look like, and the properties of the output. You also probably have an idea of what your would like it to do when it doesn't work correctly.

You can use error or exception handling to control the errors and warnings that your code produces. This can allow you to and choose:

  • Where your code breaks - by adding validation to a function input
  • How your code breaks - by providing alternate code to be run in the event of an error.
  • What it tells a user - by providing your own error messages which guide the user to a solution

There are automated techniques such as fuzzing available to check how your code and error handling responds to different inputs.