Scor­pio News

to envisage any exceptional i/o conditions and what should be done to cater for them – such as numbers out of range, or data in the wrong format. Once this has been done, one can then look into the development of an algorithm which, amounts to a well defined and complete series of operations, and will produce the results which you expect. This isn’t the sort of exercise that can be carried out on the back of an envelope!

Some folk like to use flow charts to help in the production of the algorithm but the production of a decent flow-chart is not an easy task – most people tend to become bogged down in program flow to the virtual exclusion of the program’s function, particularly when dealing with large or complicated programs. It it difficult to confine some types of flow charts to one piece of paper – no matter where one starts on a piece of paper, the @?*! chart seems to spread onto several overspill sheets! An additional problem in flow-charting occurs when the user is unsure about the amount of detail needed – so that some sections of a program are dealt with in minute detail while other sections are less adequately covered. It is perhaps best to use flow-charts to help sort out problems associated with parts of programs where difficulty is experienced or where the logic may be complex but in general, one should lose no sleep if one cannot draw one!

Program design is important and these preliminary steps should not be carried out at the keyboard – one should, initially, concentrate on producing a plan for a modular program in which each unit contains a manageable number of lines (not more than, say 30 of 40). It is a good idea to place, say, output routines into subroutines (such as GOSUBs) rather than in the main part of the program unless they are used once only. These subroutines themselves use other subroutines, so the importance of a well-structured program becomes apparent.

The best way to achieve this is by a ‘top-down’ approach in which the main part of the program is coded and then checked for errors, and the outlines of the subroutines established. The next stage consists of coding and checking the subroutines which the main program cells – and so on until the program is complete. This is the ideal situation and progress is often aided by tabulating the stages within the profram; programmers who start with the subroutines and end up with the main program may run into difficulties. Some work through from to to bottom in a linear sequence and deserve the problems which they frequently encounter. Most of us tend to start with the coding of the algorithm or whatever comprises the heart of the program and to work down to the output section then up to the Input section. There are fever snags to this approach but it is much less efficient than a well-planned top-down approach. It is always a good plan to keep a copy of the relationship of subroutines to the main program so that (if necessary) additional subroutines can be included without the bother of working out the program hierarchy all over again.

Portability

This probably causes more problems than any other aspect of programming in any language. If you are certain that your program will only be run on a particular type of machine which uses the sane dialect of whatever language you are using – well, feel free to employ any machine or language implementation-dependencies that grab you, but don’t expect your program to enjoy wider use unless you stick to ‘basic’ BASIC or ‘portable’ FOR­TRAN or PASCAL where non-standard language extensions, hence non-portability, do not apply.

This is true of programs published in this journal – those of us fortunate enough to have disks and a copy of disk MBASIC are inclined to forget that Nascom ROM BASIC is less well endowed with goodies (it’s one-third the size). The problem becomes most acute when graphics are involved – or when data I/O is required from particular ports which may have different addresses according to the manufacturers’ whims. This point is well illustrated by the problems involved in documenting the port allocations used by 80BUS beards from various manufacturers – some of whom were not very cooperative (the sage of which occupied the Editor of 80-Bus News in 1983).