Where Are We Going
Let's play the ancient game of Nim. We have a pile of seventeen pebbles. We will take
turns removing either one, two, or three stones from the pile. Whoever is left with the last
pebble loses the game.
Can you imagine how to program such a game? If your answer is "yes," then perhaps you
should stop reading and try it! If your answer is "maybe," then keep reading. So far, the
game of Nim is just an idea. That is how all programs start out. This chapter is about
turning ideas into programs.
As our programs become longer and more complicated, it becomes more difficult to
easily see what they do and exactly how they work. One tool to help us understand
programs is a FLOWCHART. A flowchart is a special kind of diagram showing the order
in which things happen in the program (that is, the flow), along with the decisions (IF-
THEN statements) that might change the flow. Five symbols are used to describe all
actions. (See Figure 1 on page 63.) Each one describes a certain type. They are: start/stop,
decision, input/output, and process. Lines with arrows connect the boxes to show
program flow. Each symbol contains a short description of the function represented by
Ovals mark the beginning and end of the program. The beginning oval should have the
word "Start" in it. The ending oval will contain "Stop."
A diamond represents decisions. A decision box has one line entering it and two lines
leaving. The two lines map the two possible outcomes of an IF-THEN test. For example,
if we have the statement:
840 IF CHOICE% = 2 THEN GOTO 1500 ELSE GOTO 1800
the diamond decision block should contain "Does CHOICE% = 2?." One point of the
diamond will be labeled "yes" with a line connected to the symbol describing the
processing at line 1500. Another point of the diamond, labeled "no" connects to the
symbol representing line 1800. In this case we have mapped a single line of the program
to a flowchart symbol. This is not always the case. Flowcharts summarize the processing.
If a symbol was used for every statement the flowchart would be as confusing as the
Decisions are so important that they usually deserve the special attention.
Input and output (I/O) are
represented by parallelograms. To
use, draw the symbol and write a few
words about what I/O operations are
taking place. An example might be
"print menu" or "input answer."
A rectangle is used to describe
processing that does not involve
decision-making or I/O. For example,
the UGUESS program from the last
chapter could have used one labeled
"get a random number in the range 1
The last symbol that we will use is
just a small simple circle. The circle
is called a COLLECTION POINT
and is used to connect two or more Figure 1. Flowchart Symbols
Let's see these symbols in action. Examine Figure 2 on page 65. This is a complete
flowchart of the program. Processing begins with the start oval. First, a rectangular
processing box obtains a random number. Then, execution moves down to the
input/output box. Compare this flowchart with the program listing. The "invite guess" I/O
box clears the screen and then asks the player to guess the number selected by the
program. Their response is symbolized by another I/O box labeled "input guess."
Then we reach the first decision box. The first question is whether the guess is correct. If
yes, execution moves to the I/O box labeled "print 'very good'" and the program ends. If
the guess is not correct, we move down the line labeled "no" out of the first decision box
into the second. This decision box tests if the guess is higher than the secret number. If
yes, then the "too high" message is printed. If no, then the next decision box is reached.
Notice that this second decision box is executed even if the greater than test is true. After
printing the "too high" message, the line continues to a connection point just ahead of the
less than test.
After the last decision box, execution is returned to the "input guess" I/O box higher up
the chart. With this flowchart it is clear to see that the only way out of the loop is to guess
the secret number and pass the test at the first decision box.
Flowcharts are good, not only for programs, but also to explain any complicated process.
For example, you could flowchart getting up in the morning and everything that must
happen to get out of the door on time. Such a chart would have plenty of decision boxes
labeled "am I late?"
Programming flowcharts are valuable in several ways. First, they explain what happens in
a program. This is what we have just done with the UGUESS1 program. The program
came before the flowchart. Now we can see in one simple picture all the tasks performed
by the program. The chart is useful if we need to explain our program to someone not
familiar with BASIC. More importantly, flowcharts are useful when we plan new
programs. As you begin to think about a program, it is helpful to draw flowcharts. They
do not need to be elaborate, carefully drawn works of art. A chart is just a tool.
Figure 2. Flowchart of UGUESS1 Program
If you understand a process well enough to do a flowchart, you probably understand it
well enough to write a program. Flowcharting helps you think through a problem. You do
not need to flowchart every step of a procedure. Use the rectangular process blocks to
cover entire subroutines. Indeed, for larger programs, you will almost certainly start this
way. Begin by drawing a flowchart that shows the major steps, the order in which the
subroutines are called, for instance. Later, other flowcharts can be drawn which detail
exactly what happens in each routine. Usually, you will find that working out the details
in the subroutines causes you to change the original chart. That is okay. It is better to find
out about changes while working on a flowchart than it is to make this discovery after
writing dozens of lines of BASIC code.