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.
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’ FORTRAN 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).