Into the ARC

Mike Williams introduces our new series for newcomers to the Archimedes, and deals in this first article with some advice on the best ways of writing a program.

INTRODUCING THE SERIES

Regular readers will know that we have featured a number of letters from RISC User members asking for information which is pitched more for the less experienced user than hitherto. Since the Archimedes was launched, to enthusiastic acclaim, many existing BBC micro owners have been among the first to purchase this new machine. Since then, the Archimedes has become an established feature of the UK micro-computer market, and is increasingly being purchased by users who have not previously owned a BBC micro.

With the increasing number of pages in RISC User, we feel that now is the appropriate time to start a new series of articles. It will be aimed at all those readers who wish to get to know their machine more fully, and to make better and more effective use of their system. The essential point is that we shall try to ensure that everything is explained in straightforward and simple terms that all readers can understand. It does not imply that we shall be dealing only with the simplest aspects of the Archimedes.

The series will often be concerned with programming in Basic, but it will cover any and every aspect of using the Archimedes, including RISC OS, as may seem appropriate. Furthermore, we assume that you probably already have an Archimedes and have read (or started to read) the various Acorn guides supplied with your system. We shall also expect you to understand something of programming already. Above all else we shall be concerned with how things work on an Archimedes, so if you have used other micros extensively, you should find much to interest you in these articles.

We hope that you will find this series useful, and even some of the 'experts' may still find they have something to learn from time to time. We would also very much welcome your own views on what this series should cover, both general and specific.

APPROACHES TO PROGRAMMING

To begin our new series I propose to look at the whole question of how best to write and develop a Basic program. Writing any program is a demanding activity, yet one which many people find highly satisfying. There is no one best way to write any program, but there are many good ideas which will help you to develop programs faster and more reliably. There is also the problem of choosing the best and most appropriate features of Basic to implement any particular task.

Basic V, the version of Basic used on the Archimedes, is a very rich version of this widely used programming language. If you have used Basic on other computers, or maybe read books on Basic which are not specific to the Archimedes, you may well be surprised (possibly daunted) at the wealth of instructions and functions which Basic V has to offer. You should also remember that Basic V, which is the latest and fullest version of BBC Basic used on all previous BBC micros, contains a good few features which have been included more to maintain compatibility with earlier and more primitive versions of Basic, rather than because they are desirable features in their own right. So you can see that it is important to know how to select the best approach to any task.

Let's get one thing clear straight away. I have seen many programs written in BBC Basic since the BBC micro was first launched back in November 1981, and there is plenty of guidance and experience on the best way to construct and write a program in BBC Basic. And yet I still see many programs which, in my view, are very badly written. What characterises these poorer programs is so often the use of the dreaded 'GOTO'.

But what is so terrible about the use of GOTO? I will tell you. Partly it is that GOTO gives no indication of what is to follow, that is, it is not descriptive of the next task the program will perform. Does that really matter? Well I, and I am sure many others, believe that it does. Few programs are written in their final form first time, so that they work immediately and are never modified.

A better approach is to use a function or procedure. This means identifying a task within a program, and then writing the code for that task and giving it a unique meaningful name, so that whenever and wherever that task is required we need simply refer to it by name. That makes any program much easier to follow and understand; it also makes a program much easier to develop in the first place.

Furthermore, in my experience, the use of GOTO often leads to a poor and inefficient style of programming culminating in the so-called spaghetti program apparently containing little more than hordes of convoluted and intertwined GOTOs. This is all very indigestible, and quite unnecessary in virtually every case. So banish the GOTO from your own programs, and it will transform your programming overnight (as they say).

DESIGNING A PROGRAM

Suppose you want to write a program for some purpose. How should one best approach this task? In the most trivial of examples you can probably just sit down at the keyboard and type in the instructions. The result may be a little crude, but it usually doesn't take long to get something working. This approach is quite adequate for short, often temporary programs that you may need to write from time to time.

Most programs will, however, benefit from some thought and planning before you put hand to keyboard. Often, you may at the outset have only a vague and general idea of how you want something to work. That doesn't matter, as the use of functions and procedures is ideally suited to cope with this. Experience also plays a major part, and the more programs you write the more you are likely to feel that initial planning is unnecessary. Beware! I have fallen into this trap, and ended up spending much time sorting out the logic of a too hastily written program which would clearly have been avoided by better initial planning.

So what should you do? Well, the traditional mainframe approach was to draw a detailed flow chart before writing any code whatsoever. But the advent of 'instant action' micros has changed that. I would not now recommend a fully detailed flowchart, but they still have a useful role to play in ensuring that any routines where the logic is likely to be complex, are properly thought out in advance. Get the principles right and the implementation in Basic is far less likely to be wrong.

The approach which I generally favour is quite simple: just write down in ordinary (maybe abbreviated) English what you want your program to do. Initially this may look quite vague, for example:

Initialisation
Set up screen display
Repeat
Get user input
Process input
Display results
Until finished

Even without adding any more detail at all, we can convert this into a program in Basic using procedure calls, thus:
100 PROCinitialise
110 PROCscreen
120 REPEAT
130 PROCinput
140 PROCprocess
150 PROCdisplay
160 UNTIL finish
170 END

Now that won't work if we type it in and try to run it because none of the procedures has been defined. Even though we don't know yet what each procedure will do (in detail), we can still write sufficient to make everything work. So add:
1000 DEF PROCinitialise
1090 ENDPROC
1100 :
1200 DEF PROCscreen
1290 ENDPROC
1300 :
1400 DEF PROCinput
1490 ENDPROC
1500 :
1600 DEF PROCprocess
1690 ENDPROC
1700 :
1800 DEF PROCdisplay
1890 ENDPROC
1900 :

The program will now work correctly, but will achieve very little as all the procedure definitions are empty. We have in effect created a skeleton for our program. We can now proceed to add the flesh.

The next step would be to take each procedure definition in turn and begin to fill in the detail. It may be that you can directly type in the necessary Basic instructions. If it is at all complex you may find it easier to write down a description first, and you will often find that the best solution is a mixture of detailed Basic and calls to further procedures or functions yet to be defined. For example, the procedure PROCscreen might be described as:

Display title
Display instructions
Display menu

The precise structure, and the choice of procedure names, will depend on your own application, but the principles remain the same.

What is also important is to fill in the detail a step at a time, and to test as carefully as possible each step before moving on to the next. Type in the instructions that will make up PROCinitialise (setting any starting values for variables, arrays, and any other settings - cursor off for example), and then test that this is correct before implementing the next procedure.

This is clearly an ideal approach, and one which may seem over laborious. The choice is yours. I am sure that we have all rushed on occasion in adding too much code without proper testing, only to regret our haste later. Even large and complex programs can be implemented successfully by this stepwise approach, gradually refining the levels of detail within the program, and testing carefully at each stage. The essence is the division of any program into small independent but linked routines. Each routine is then small enough (about 20 lines of code is the most which is manageable) that it is easily understood, written and tested, whereas it quickly becomes quite impossible to cope at once with everything in a complete program.

PROGRAMMING STRUCTURES

One further aid in Basic V is being aware of and using the many different structures which are provided. All versions of Basic allow a FOR-NEXT loop which counts the number of times that the enclosed code is repeated. Basic V also provides REPEAT-UNTIL and WHILE-ENDWHILE to implement conditional loops, where the number of repetitions is not known in advance but determined by a condition which is repeatedly tested. As with functions and procedures, try to make loops self-contained pieces of code.

As well as a repeated section of code, the other essential requirement of any programming language is the facility for the program to choose between two (or more) alternative courses of action dependent upon data values at the time. The simplest form is the standard IF-THEN-ELSE, but Basic V also provides a much more comprehensive IF-THEN-ELSE-ENDIF structure which avoids the obvious (and sometimes less obvious) ambiguities of the simpler and more standard form. What is particularly useful in Basic V is the presence of a CASE statement. This is a device for choosing one from a number of alternatives, and is a much more effective means of doing this in many cases than using multiple or nested IF-THEN-ELSE statements.

In all these respects, Basic V has very much more to offer than implementations on most other machines. All of the structures which I have referred to have an important role to play, and we shall be looking in more detail at the practical use of many of these in future articles in this series. If you are not already familiar with these programming techniques, then I suggest you look them up in the guides that come with your Archimedes and begin to use them in your own programs. They are well worthwhile.