G<X
Start
Generate X (1-99)
N =0
Input Guess G
G=X
End
Other types of algorithms can be used to deal with very complex situations, where a particular rule is found to give good results and is used for lack of anything better. Complex chess openings can be generated with quite simple algorithms, moving to maximize the area under attack and minimize the opponent's range of replies.
Program 4- 1. Guessing Game o
REM * GUESSING GAME *10 PRINT "{CLR}GUESS MY NUMBER (1-99) ": PRINT 20 X=INT(RND(1)*99)+1: N=0
30 INPUT "YOUR GUESS"rG: N=N+l
Effective Programming in BASIC
4117 IF G<X THEN PRINT "TOO SMALL": GOTO 30 5117 IF G>X THEN PRINT "TOO LARGE": GOTO 3117 6117 PRINT "GOT ITt IN " N "TRIES"
The algorithm used in this guessing game is shown in Program 4-1. As you can see, it is a fairly simple one. Lines 0-30 correspond exactly to the first boxes of the flow chart; after this, because IF allows only two options, the lines cannot exactly match boxes but the logic is identical. Note that line 60 doesn't need to test IF G=X, since no other possibility exists.
Testing (and probably improving) the program. There are usually ways to im-prove a program's design. In this example, you could add line 70 FOR J= 1 TO 3000:
NEXT: GOTO 10, replacing the box END by a delay loop and a branch back to PRINT TITLE. Values could be checked to make sure they are in the correct range (and that they are integers), or the screen layout could use color.
Testing is difficult. In fact, commercial programmers spend most of their time removing bugs from programs. Ideally, with everything about a program planned in advance, bugs would not appear. But in practice it's impossible to plan for all eventualities.
An Example of a System
Later in this chapter is a program called "Wordscore" which assesses five-letter words on a score-per-Ietter basis. One form of this game scores words reading across a 5 X 5 grid, where the word BINGO must be included vertically in anyone column or diagonally from top left to bottom right. Can VIC help?
The first step is to assess the potential data base of words. A typical dictionary lists about 2000 five-letter words, but not all of these will contain one or more letters from BINGO. VIC can handle this, and the demonstration shows how any values can be assigned to letters A-Z before checking the tape file. Keying in the data is not too long a job. Adding BASIC to select the highest scoring words of form Bxxxx, Ixxxx, and so on (29 relevant formats) isn't difficult, and the conclusion is that VIC could be valuable here.
In general, system planning requires four steps. They are given here in order.
Ask if it is feasible. Can a program system reasonably handle the job? Time may be a problem; sorts, searches, graphics, or tape processing may be too slow to meet your requirements. You may have to write a test program to check these things out. RAM space may also be a problem, particularly with the unexpanded VIC. Can the data coexist with BASIC? Would splitting the program into smaller subprograms help? The list goes on.
Less tangible problem areas might include reliability or recovery of lost data if a tape or disk is lost. A little time spent addressing these questions may save time later on.
Write a solution. Again, you will need to develop suitable algorithms to solve the problem at hand.
Write the program(s). These should be structured so they are easy to under-stand later. Programs written in modules, each having a single entry and exit point, are likely to be easier to maintain.
Figure 4-2 shows two charts which may be used; one shows a file's structure, while the other illustrates a modular program structured to read that file. Table 4- L a condition table, lists alternative actions in tabular form and allows complex decisions to be checked more easily than spaghettis of IFs permit.
Figure 4-2. File Structure and Related Program
Open Files
Read eader
Table 4- 1. Condition Table
Conditions: Stock> reorder level?
Stock minus stock out> reorder level?
Stock out > stock?
Actions: Issue stock
Issue reorder request Part issue stock I increase commitments
Read Until End
Y Y N X
-Read Trailer
Control Level
Close
Files Modules
Subroutines
Y Y N N N
N N N N N
N Y N Y N
X - X
-
-X X - -
-- X
-
X-Test the system. The final step is to test the system, to see if it functions as de-sired. See the next section for a detailed discussion of system testing.
Programming Considerations
Unless you're subject to external constraints (for instance, a house style), there is no correct way to program. If it's your computer, you can do what you like. However, this section examines a number of considerations which are important to a program's readability, ease of maintenance and modification, user-friendliness, and so on. In each case you must decide whether inclusion of the feature is worth the additional effort.
Conventions for line numbers, variable names, and REMs. You may choose to number active lines by fives or tens, putting REMs only on lines whose numbers end in 9. If standard subroutines are used, retain the same line numbers in different programs.
Effective Programming in BASIC
REMs help readability, but take up space; you may find it worthwhile to docu-ment standard routines for future reference, and delete REMs from programs.
As for variables, remember that BASIC uses global, not local, variables. Be sure that variables can't be accidentally changed. Either list every variable as it's used (and make variable names meaningful), or establish a convention that you will adhere to.
Documentation. Paper documentation could include an operator manual (explaining how to switch on and off, handle and copy disks, and so on); a user manual (explaining file structure, validation methods, and correct sequence of grams); and a system manual (providing a complete reference to the system pro-grams, specifications, file structures, and so on).
Ease of modification. Hard-coded programs use large numbers of constants;
soft-coded programs rely more heavily on variables. As a rule, soft coding is easier to modify but more trouble to write.
Error messages. These signal that a mistake has been made, and, more im-portantly, tell you what it was. Some are built into the computer; you can build others into your programs to make them easier to use.
Easy INPUT of data. A simple INPUT is fine in many cases, but it doesn't give full control. It is better to test for and disable all keys except those actually desired for input; integer input must accept only numerals and not cursor keys, colors, let-ters, and the like. STOP and RESTORE may need to be disabled (see Chapter 6), and the length of the integer checked. None of these is very difficult, but all take
programming time and use up memory.
Prompts are also important. Instructions like ENTER THE AMOUNT or ENTER NEXT ADDRESS make programs much easier to use, but (again) take time to write and occupy memory.
Convenience is another aspect to consider; for instance, a HELP command might also be included. In addition, correction of data can be simplified by printing 10 or 20 values on the screen and asking the user to indicate any changes that might be needed; if so, a minimum number of keystrokes are necessary.
Menus are like elaborate prompts that help users find their own way through programs. A menu displays several options from which the user selects one, typi-cally by pressing a single key. If a menu program stands alone, it has to load and run a new program; alternately, most or all of the options may exist together in memory.
Output formatting. Neat output, particularly of numbers, requires some work.
There are a number of ways to format output; for instance, PRINT USING in Chap-ter 6 gives you a way to print numbers as, say, 2.00 instead of 2.
Subroutines. Standard subroutines allow programs to be developed and tested as modules. It is easier to check isolated parts of BASIC than entire programs; break-ing a program into sections also makes it possible for several people to work
simultaneously, provided the variables and line numbers are agreed on beforehand.
Subroutines often save space and should always improve clarity. In fact, if your aim is to enhance clarity, it may even make sense to write subroutines which are only called once.
Testing. Thorough testing ideally checks every possible combination of data.
Generally, this is impossible. In practice, depending on the program or subroutine, a
loop may be used to generate ascending values or check their effect, or RND may be used to make up strings or numerals of the right size. The program "Rounding" later in this chapter includes a loop demonstration; Chapter 6's sorting routines use ran-dom data to test sorting.
There are several potential problems that you should be aware of when testing.
First, there may be extreme or boundary values which have strange effects; negative numbers, numbers below .01 (which are printed in exponential notation), and the double quotes key are likely to wreck input subroutines unless they're tested for and removed. Second, programming errors may show up only when several events occur at once, making bugs hard to trace because of their apparent random appearances.
Third, unconscious bias may influence the choice of test data. For these reasons, commercial systems are tested with data supplied by the user, who also checks that the output is what it should be. However, this can cause problems since the user may not appreciate the importance of testing with obviously wrong data which the system ought to reject.
Validation. Validation is the process of checking to see that data is of the cor-rect type, without necessarily guaranteeing the actual values. For example, although 19/19/86 is an invalid date which should be rejected, 9/9/86 is valid but may be wrong. In its simplest form, validation simply repeats the request for data. More sophisticated checking includes error messages.