Radio Shack TRS-80 - Page 174

4.
Accidentally
including
"equals",
as
in "less
than or
equals",
when you
really
mean only
"less
than."
5.
Confusing
similarly
named
variables,
particularly the
variable
A,
the string A$,
and the
array A(X).
They are not at
all related.
6.
Forgetting
the
order of program
execution
—
from left to right on
each
line, but
multi-
plications
and
divisions
always
having
priority
before
additions and
subtractions.
And
intrinsic
functions
(INT, RND,
ABS, etc.)
having priority
over
everything else.
7. Counting
incorrectly in loops.
FOR
1=9
TO
7 causes the
loop
to
be executed eight,
not
seven, times.
8.
Using
the same
variable
accidentally
in two
different
places. This
is
okay
if you don't
need
the old
variable
any
more, but
disastrous
if you do.
Be especially
carefuly
when
combining
programs or using
the
special
subroutines
in Chapter 25.
But how
do
you
spot
these
errors
if the
Computer
doesn't point
them out? Use
common
sense and
let the
TRS-80
help
you. The rules to
follow are:
1. Isolate
the error. Insert
temporary
"flags." Add STOP,
END, and
extra
PRINT state-
ments
until
you can
track
the error
down
to one or two
lines.
2.
Make
your
"tests" as
simple as
possible.
Don't
add
complications
until you've
found
the
error.
3.
Check
simple cases by
hand to test
your logic, but
let the
Computer
do
the hard
work.
Don't
try to
wade
through
complex calculations
with pencil and
paper.
You'll
introduce
more new
mistakes
than
you'll
find. Use the
calculator mode, or a
separate
hand
calculator
to
do
that work.
4.
Remember
that you
can force
the Computer to
start
running a
program at any line
number
you choose.
Just type
RUN
#*#
(where ###
represents
the desired line
number).
This is
a
useful
tool
for working
your
way back
through
a program. You give
the
variables
acceptable
values
using
calculator-mode
statements,
and then RUN the
program
starting
from
some point
midway
through the
program flow. If the
answers
are what
you expect,
then the error is
before the "test point"
you've created.
Other-
wise,
the error is
after the test point.
5.
Remember
also
that
it's not necessary to
list the entire
program
just to get a
look
at
one
section
of it. Just
type
LIST
###
(where
### tells the
Computer which line
you'd like
to
start the list
with).
6.
Practice "defensive
programming." Just
because a program
"works okay",
don't
assume
it's
dependable.
Programs that accept
input data and
process it can be
especially
decep-
tive.
Make a point
of
checking a new
program at all the
critical places. Examples: A
square root
program
should be checked
for inputs less than
or
equal to zero. Math
functions
you
have
programmed
should be
checked
at points
where
the function is
undefined,
such
as
TAN{90°).
olusefftl flags:
299
PRINT
LIME
#'Z.9¥".'
399
IF
x.<& THEN ^RINT
"XOUI HF
RANGE AT
#399"; STOP'-
Line 239
will help
you\
check whether
the line'
immediately
following
line
299 is
executed.
This
helps you
follow
program
flow-
Line
399 might
be: used
to
locate
the point where
X
goes out
of
range.'
Although
the details
would
be
different for your
program,
tftesfe techniques
can be applied
easily.
172