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.