Readers Feedback

The Editors and Readers of COMPUTE!

If you have any questions, comments, or suggestions you would like
to see addressed in this column, write to "Readers' Feedback," COMPUTE!,
P.O. Box 5406, Greensboro, NC 27403. Due to the volume of mail we
receive, we regret that we cannot provide personal answers to technical
questions.

The Ideal BASIC Style

Some time ago I read a letter in your magazine regarding crunching of
program listings and the effect this has on readability. You replied
that this was to save memory and magazine space. I would like to suggest
a reasonable compromise between readability and the elimination of
spaces. In my view, any statement that juxtaposes two letters (for
instance, FORT=1TO10 or IFS=5) would benefit greatly from extra spaces
(FOR T=1 TO 10 or IF S=5). But if a number follows a letter (as in
GOTO600 or THEN470), the statement is understandable even without an
extra space. I think DATA should always have a following space so the
first value stands out clearly. You are often inconsistent in this, even
within the same program listing. As to multiple statements in one line,
this in itself creates no problems and is necessary in some cases. But I
don't believe that completely unrelated statements should be put on the
same line simply to fill up the
line.

Line numbering is another area. You use the time-honored decade
numbering (line increments often), which is fine when developing a
program. Finished programs are usually renumbered for neatness, but I
don't see why nine skipped numbers are necessary. I suggest that you use
every other number instead (1, 3, 5, and so on). This would allow
someone. to insert a STOP or GOTO while checking for typing errors or
making minor alterations. The big advantage of this system is that
decade numbers could have special meanings as important entry points or
the beginning of a new group of closely related statements. For example,
a complex FOR-NEXT loop might use several lines, then jump to the next
decade line number for a new group of related statements. It would be
much easier to follow and understand the flow pattern.

I also feel there could be at least
partial standardization of some of the
most common variable names. For instance, the variables I, J, and K are
ordinarily used as "junk" variables
(counters within loops, and so on). The
variables X and Y are frequently used to
specify horizontal and vertical coordinates. But many others are commonly
used as well: SA for starting address, FA
for ending address, CK for checksum, and
so forth. You could publish a list of
suggested variable names and encourage programmers to stick to it.

Don R. King

As long as programmers use BASIC, there will be discussions about
what sort of style and structure BASIC programs ought to have. The
reason for the controversy is familiar. BASIC imposes few structural
constraints on the programmer, so the language is easy to learn and
works well for improvisational programming and quick experiments. But
its lack of structure also makes it possible to write tangled, illogical
"spaghetti" code. Since BASIC doesn't force you into a predetermined
mold, a program can take nearly any form. More structured programming
languages such as Pascal generate more readable code, but demand more
forethought on the programmer's part.

Most of the programs we publish are submissions from readers.
Generally, we modify these programs only to eliminate any bugs that
appear during testing or to add functional improvements. Any time you
change someone else's program, you increase the likelihood of
inadvertently creating new bugs which even the author may not have
anticipated. Given the number of programs we publish and the constraints
of monthly deadlines, it's not practical for us to rewrite working
programs merely to improve their readability.

A carefully planned numbering scheme can add to a program's
readability. But our programs are meant to be typed in from a printed
listing as well as studied. So we need to do everything possible to help
readers type the programs without errors. Numbering in regular
increments makes it easier to keep your place in the program than if the
increments changed at unpredictable intervals. Uniform numbering also
helps readers spot lines that have been left out altogether (a typing
error that no proofreader program can catch). However, sometimes even
the simple act of renumbering a program can introduce new bugs---as has
happened to us in the past.

It's also true that if everyone followed the same stylistic
conventions, BASIC programs would be more readable. The difficult part
is getting programmers to go along with the conventions you choose,
especially considering that each version of BASIC has its own
peculiarities- For instance, Commodore BASIC doesn't require spaces
after keywords (and omitting spaces speeds program execution), but some
other versions of Microsoft BASIC insist on a separating space. Other
BASICs, such as Atari BASIC, automatically insert spaces for readability
if you leave them out.

Different dialects of BASIC also include different keywords. For
instance, NAME is a legal variable name in Commodore BASIC, but it's
treated as a reserved word in IBM BASICA and Amiga BASIC. In Commodore
and Apple BASICs, only the first two characters of the variable name are
significant, and you may not embed keywords in variable names. But IBM,
Atari, and Amiga BASICs permit long, descriptive variable names such as
MousePosition or MenuFlag which can include embedded keywords. The list
of differences goes on and on. Given the diversity among BASIC dialects
and the absence of standardization, any list of preferred variable names
would have to be exceedingly general and geared toward the lowest common
denominator.

As time goes by, Microsoft BASIC seems to be taking over as the de
facto standard for the language. Newer, more powerful computers such as
the Macintosh, Atari ST, and Amiga all offer versions of BASIC that more
closely resemble IBM BASICA. With the exception of graphics and sound
statements, which are necessarily hardware-specific, a program that runs
on the IBM, Mac, or Amiga will probably run on any of the others with
only slight modifications. If this trend continues, we may someday reach
the point where BASIC style becomes more homogeneous.