ZX Computings - OpenLibra

writing, the purpose is all too
clear but after a few weeks or
months the memory fades.
4) Is the textual material on
the VDU easy to understand
and pleasantly arranged?
There is no excuse for sloppy
presentation and curt chunks
of computer jargonese
interspersed with
abbreviations. Just because
the computer has no soul or
manners this is no excuse for
omitting the pretence. A little
care taken in presentation will
give the pleasant illusion that
lurking behind the cold
rectangular sheet of glass is a
"being" with a heart of
gold . . . kindly and paternal
when the occasion warrants it
and yet hesitating to deliver
streams of pure vitriol if its
human operator enters silly
figures or presses wrong
buttons. In other words, give
your computer a personality.
Space out the text in a
readable manner, Nothing is
more tiresome than a page full
of closely spaced reading
matter, particularly if it is
composed entirely of capitals.
There is no need to stuff
everything on one VDU page
but never allow the pages to
scroll. Text creeping up from
the bottom and disappearing
at the top should never be
tolerated; it is unpleasant to
read and amateurish.
Expansion
5) Is the program planned
with the idea of future
expansion or improvement in
mind? No program can ever be
perfect and equally true, no
program can ever be
absolutely complete. There
will always be the nagging
doubt, particularly when it is
re-run a few weeks later, that
some extra facility or twist
should have been added. In
many cases however, this can
be a difficult or even
impossible task. In the first
case, the program may be
utterly incomprehensible when
LISTed if several weeks have
elapsed since it was written.
Juggling with obstinate
statements, temper,
frustration and the other
multitude of ills popular during
program construction
eventually leads to a transient
state of euphoria when the
beast finally decides to work.
There is a mad rush to "get it
on to tape" and indulge in a
satisfying bout of selfcongratulation.
It takes a little while to
appreciate the value of the
REM statement because at the
time, it seems unnecessary. In
fact some of us deliberately
leave out remarks in order to
prevent other people
understanding how our
masterpiece works. This
attitude can be selfdestructive
because the writer
of the program may eventually
become the victim. Another
obstacle to future amendment
is a poorly structured original
and close-packed line
numbers. Never start a
program with line number less
than 100 in case some extra
stuff may have to be squeezed
in at the head. Be methodical
in the choice of subroutine line
numbers. Stick them all
together well down the
bottom, say at line 9,000
onwards. In this way, you will
avoid the ugly embarrassment
of having to leap frog over
them with a wasted GOTO
statement when the lines start
to creep down further than the
original estimate allowed.
The term "program
structure" of course means a
lot more than the mere
organisation of line numbers.
Library
It means laying out a program
in neat little modules, each
capable of being individually
tested in its own right. In fact
there is a specific
programming philosophy with
many little rules and
regulations resting beneath
the blanket title of
"STRUCTURED
PROGRAMMING". This is
worth detailed study if only to
know when to break some of
the rules.
Programs To
Write
Advice on what programs to
write is about as difficult as
advising on the best length for
a piece of string. An overall
piece of advice is simply to
walk before you run. Don't
attempt to write wildly
ambitious programs unless
you are quite certain you
understand the full
implications of the task ahead.
Unfortunately, it takes some
experience to know in
advance whether or not a
certain programming task is
likely to be easy or horribly
difficult; computers are odd
things.
For example, if someone
came and asked me to write a ^
program to print out a table of
the singular solutions of a
second order differential
equation I would take the
money in advance and
probably deliver the goods
(suitably tarted up in
accordance with the previous
advice) the next day. This is
not because maths and
physics is my strong point (I
might pass O-level maths with
difficulty) but because the
actual maths details must
reside in some text book
equation somewhere or other.
It would just be a case of
letting the faithful old BASIC
interpreter handle the sordid
details once the correct
sequence of brackets and
operators have been entered
from the text book to the
VDU.
Such programs are
elementary number crunching
exercises, impressive but
routine. On the other hand, a
request for "a little program to
30 ZX COMPUTING SUMMER 1962 Z