A-level Computing/AQA/Problem Solving, Programming, Data Representation and Practical Exercise/Fundamentals of Programming/Fundamentals of Structured Programming





You should already have seen how you can use structure tables, structure charts, hierarchy charts and procedures/functions in breaking down a complex task. This section will look at how to write the best formed and most readable code we can.

If you want to be a good programmer (and get good marks in the exam) then you have to make sure that your code is easily read by other people. There are several things you should try and do when coding:

Use procedures that execute a single task
Each procedure / Function does a single thing, such as calculate the current health of a player in a game. This means you can then use them as building blocks to build bigger solutions. If you make your procedures / functions do too many things at once, then they are very hard to re-use in different projects and difficult to test.

Use procedures/functions with interfaces

 * Breaks the problem into chunks
 * You can test each separately
 * You can reuse code

Use sensible variable datatypes
Make sure that the datatype you use are sensible. You will get marked down for using the wrong datatypes in your database tables and variables.

For example: If you are recording the total number of chocolate bars in a shop you don't need to use a Long or Float, you can only have whole numbers of chocolate bars and it is unlikely you'll have over a few million items. Use an Integer!

Meaningful identifier names
When you are declaring parts of your program and you return to the code some time later, you want to be able to understand what each variable, procedure and function does without having to trace out the code. The easiest way to start doing this is to name them correctly:

Use sensible variable names
If you are using variables to store things they must have a name that makes sense so you know what it does when you read its name in your code.

For example: If you are recording the total number of chocolate bars in a shop you don't want to use a name like variable1. What does variable1 mean? Use a sensible name such as NumChoc.

Use sensible Function/Procedure names
If you are creating subroutines to process things in your code make sure you give them a sensible name so that people know what they are doing when they see them in the code.

For example: If you have written a piece of code to calculate the average price of a chocolate bar then don't call it FunctionA, what does FunctionA mean?! Call it ChocAverage.

Try to stick to one naming convention
If you are using lots of variable names and function names, stick to a single style for naming them. If you use lots of different conventions things are going to look ugly. Wikipedia guidance

For example:


 * firstName, lastName, calculateDoB, numLegs
 * FirstName, LastName, CalculateDoB, NumLegs
 * First_Name, Last_Name, Calculate_DoB, Num_Legs

Don't make your names too long
Long variables can be very hard to read and much easier for you to make mistakes when writing them, try to shorten things where possible.

For example:

Indent your work
A lot of programming environments help to indent your code automatically and you should be able to find one for the language you are using. Indenting helps people to read and understand your code quickly as it clearly shows the structure of functions, procedures, selection and iteration statements. For example the following is very hard to read: If you indent it is becomes much easier to read:

Use comments where necessary
Some of the best written code doesn't need comments because if you have structured it correctly and used all the proper naming conventions it should be pretty easy to read. However for the code you are writing you should put some comments to explain what each section does.

The advantages of the structured approach

 * Easy to read and fix code
 * Problems broken down into easy to manage chunks
 * procedures / functions are reusable, you can use them in different projects.
 * You can test modules individually

What might be considered wrong about the use of the subroutine above? How could it be fixed?

The sub routine is performing multiple function: it calculates the total AND the average. Functions/procedures should only perform one task at a time. You could replace the above with two subroutines:
 * calcAvg(...)
 * calcTotal(...)

List three reasons for using functions and procedures to structure your code


 * You can re-use the code
 * You can test parts of the code individually
 * The code is easier to read and understand

Give three structured programming techniques that could be used to improve the code above:


 * proper use of indentation
 * sensible variables names (why on earth have they used  to store the age, why not use  ?)
 * use comments