Title: Structure, Part 1

Author: Martin Moene

Date: 17 June 2010 08:55:00 +01:00 or Thu, 17 June 2010 08:55:00 +01:00

Summary: How to get some into your C programs!

Body: 

Introduction.

In this series of articles I'll talk a bit about structuring 'C' programs. Although aimed at the fairly recent convert to 'structured' languages, the series may contain points of interest to more experienced users. In this first part we'll try to identify what structured programs are.

The Holy Grail.

Like some Holy Grail, we talk about this thing called structured programming. Everyone has heard about it, few can explain it, fewer still seem able to produce structured programs. Our students are told about the benefits of using structured languages like Pascal, but few seem completely at home with the whole idea. It's not difficult! Most of it is common sense really. Like everything - you get better with practice. Let's have a look at this magic and try to dispel some of the myth.

Engage brain.....

One good starting point which is definitely worth mentioning again - leave the keyboard alone! I'm sure that the big problem with many new programmers (and I was no exception) is their eagerness to get coding. This is not a good plan. When you're typing at the keyboard - coding or whatever - you are too close to the problem to see the 'big picture'. It's too late. Within the first few minutes all hope of structure will have gone. So STOP. Think a little before you code.

Now let's see if we can tell how to identify structured programs:- that should make the task of achieving them that much easier.

What's in a language ?

Surely, if we use a language like Pascal or C then our worries are over ? They are designed as structured languages. They force certain logical constraints on us. Why need we say more ?

Let's start by asking some questions.

• What is structure ?

• Why use structure ?
• How do we identify good structure ?
• How do we produce good structure ?
• Can we define a set of rules to help us ?
• What makes a good procedure ?

We'll have a look at each of these questions and, as we build an understanding about what is and is not structure you will begin to see how to achieve it.

What is structure ?

Perhaps it's easier to start by saying what is NOT structure. Let's take a popular example - that of making a cup of tea. A simple enough job and one made up from a set of clearly definable steps. Here are some of the things we would have to do:

11	Pour tea in cup.	9	Put tea in pot.
4	Fill kettle.	6	Warm tea pot.
7	Put water in teapot.	12	Stir cup.
8	Open tea caddy.	2	Check if kettle filled.
10	Put milk in cup.	1	Check if teapot empty.
3	Turn on tap.	13	Drink tea.
5	Boil kettle.	14	Pick up kettle.

Well, most of the things that need doing are there, but there's not much structure to it I'm sure you'll agree. It doesn't make sense to warm the pot AFTER we've put the tea in it! Clearly, the actions are in the wrong order. There's another problem too - we can't get any sort of overview of what's going on -we don't see the general outline of the task; we've got to look at lots of detail to see what's going on.

Now here's the same problem presented in a different way:

 Pick up teapot, open lid, check if full, close lid.
 Pick up teapot, open lid, empty old tea, close lid.
 Pick up kettle, open lid, check if full, close lid.
 Pick up kettle, open lid, place under tap, turn on tap.
 Check if kettle full, turn off tap, close lid.
 Plug in kettle, switch on power, wait for kettle to boil.
 Switch off switch, pick up kettle, open lid of teapot.
 Pour in water, warm pot.........

We've been going for ages and we're no-where near a cup of tea yet! What's wrong this time ? The general actions are correct and in the correct order but the purpose is obscured by detail. Open and close lids everywhere! If you didn't know what was going on you'd be asking 'What's going on here ? What is he trying to do ?'

Notice that in both these cases the actions are correct. The result will probably be a cup of tea. Structure therefore, is nothing to do with whether or not the outcome is correct. Witness the hundreds of totally unstructured programs there are around. You could write an infinite number of programs to achieve a working result and none of them need be structured.

However, structure does assist in reaching a functioning program and also in modifying a program.

Why do we use structure ?

Realise that no program will work perfectly first time. Therefore, take steps to make life easy on yourself. Modifying a program is something done during development too. It's not just something that happens years later. If you think you'll remember what's going on after a couple of months then you're probably wrong. Conditions change. The problem you started off writing a solution to may not end up as the same problem. Either you will see better ways to do things as you get further into the project, or the person you are writing it for will change his mind. It makes sense to build redundancy and versatility into your programs.

Firstly for your own use, so that you can easily reuse the things you have written for another project. Secondly, as I have said, the program you write to make one cup of tea is likely not to be for just one cup of tea at the end of the day, eg. If we decide to use a kettle which doesn't have a lid, think of the number of places we need to change a line in our second list of actions.

If we want to boil two kettles at once or make ten cups of tea - how can we handle that? (Especially if our teapot can only make five cups of tea at once.)

Special case ?

Try to take a step back from the problem, avoid the detail and look at the broad steps. Try to think ahead to likely future changes and try to identify the 'special cases' implicit in what you are doing, eg. making a cup of tea is a 'special case' of making 'n' cups of tea where:- n = 1, and boiling a kettle is a just boiling 'n' kettles where:- n = 1.

This last point is true of almost every problem you will face. Sometimes situations are such that you know you need never consider more general cases. Often, however, realising that something is a special case is a positive help. Let's look at another example:- find the average of 10 numbers between 1 and 100.

This is a special case of finding the average of 'n' numbers between 'min' and 'max' where:- n = 1, min = 1, and max = 100

If you recognise these points early on in your thinking, it will alter the way you consider each step. Boiling the kettle is no longer just something that needs to be done at some point. It is a self contained task which we will request simply as 'boil kettle'. We need not concern ourselves with lidless kettles or about whether it was part full or empty. As a first step, all we need know is that there is a task (procedure, function or subroutine) which, if we call it, will result in us having a boiled kettle.

Of course, at some point we must put in all the necessary detail into boil_kettle(), but let's not think about that just now.

If you can achieve just these two objectives:

• Concentrate on high level actions ignoring the detail.
• Recognise special cases.

then you have made a good start in structuring.

In the next part we'll begin to formalise our definition of structure and try to produce a set of maxims to work with.

Notes: 

More fields may be available via dynamicdata ..