Title: Structure, Part 3

Author: Martin Moene

Date: 28 June 2010 08:52:00 +01:00 or Mon, 28 June 2010 08:52:00 +01:00

Summary: 

Body: 

In this series we have been considering how to achieve structure in our programs and have identified some key issues:

To produce a structured program we must:-

• Concentrate initially on high level tasks.
• Recognise special cases.
• Produce simple, single entry/exit processes.

Understand the problem.

Now, we have said nothing so far about how you are solving the problem, the algorithm or methods you are using, but concentrated on how you go about laying out the chosen method.

So perhaps it is worth stating that, before you begin any sort of work, you must fully understand WHAT you are trying to do and HOW you are going to do it. The best structure in the world will do nothing if the algorithm is wrong. However, if the algorithm is wrong, if you've structured your program well, finding and fixing the problem will be a lot less painful.

Thinking back to our original problem. If we realise late on that our algorithm for opening the lid of the kettle is wrong, then we only have to change the detail INSIDE that procedure. Where it's called from, the body of the program, remains the same. Structure has helped us. We don't need to go through 200 lines of code looking for affected lines.

This early stage of thinking of the problem and deciding on the algorithm and then laying out the broad steps is crucial. It's the most difficult part of the whole process. Get things wrong at this point and you make work for yourself later on. I'm going to say that again because it's important. Get things wrong at the initial algorithm and main body stage and you make work for yourself later on. So take the time to think it through.

Here are some tips to make this easier.

• Just write out steps in plain English first.
• Play 'what if' games with the data/input.
• Think about what it will look like or actually do in the end. Is whatyou're planning now going to give this ?
• Allow your mind to wander off down a couple of levels at each step withoutgetting too detailed, just to see if things seem to flow OK.
• Think about how you are handling the data. What data structures or typesare you using ? How will they be passed from function to function ?
• What function needs to know what - is that data going to be available atthat point in the process.

For trivial tasks these steps are easy. The more complicated the task, the more essential it becomes to do each correctly.

Having done this on the top level then really the same procedure can be repeated for lower and lower levels.

The story so far..

Structuring then makes use of several key points:

• The program will be constructed on a hierarchical basis with each levelrestricted to handling tasks and data applicable to that level. Theoverall purpose of a level will not be obscured by detail relating tolower levels.
• Data structures and variable names will be chosen to suit the particularlevel.
• At the highest level only broad outline steps will be identifiable.
• Each procedure will follow a single entry, single exit pattern. Loopconstructs such as for() while() and do() will be used to provide repeated sets of instructions.
  Where nesting of loops, or the number of instructions within a loop, is more than 3 or 4, then consideration will be given to creating a further sub level function to hold these instructions.
  In this way the broad purpose of the loop is not obscured by heavily detailed loop bodies.
• Functions will be laid out on the page in such a way that the use ofcomments, headings, indentation and whitespace make the level and purposeof the function clear.
• Procedures will be constructed as far as possible in a general purposemanner such that changes to the boundary conditions, number of iterationsor data does not substantially affect program layout.

Next time we'll consider how the choice of data type can help us in structuring.

Notes: 

More fields may be available via dynamicdata ..