currently running is trapped inside an endless loop.

One way to remember these elements of the while loop is to think back to the for loop syntax. The for loop structure requires you to think about the characteristics of a well formed loop. You are required to define and initialize a sentry variable, define a condition, and ensure that the variable changes to a value that can trigger the end of the loop.

Planning Your Program with the STAIR Process

You are learning a lot of new syntax and many new strategies for thinking about information and programming. However, all these skills and syntax details are not the most important part of the programming process. You can always look up syntax or find a new command on the online help. The most challenging part of the programming process is the creative aspect. You have to be able to visualize a problem and apply a solution to that problem. You also need a framework for your solution so that you don’t find yourself staring at a blank screen, wondering what to do next. The next section helps you create that framework.

You don’t have to take a class in software engineering or project management to take advantage of good planning strategy for writing your program. I was part of a group of computer scientists at Indiana University which devised a strategy named STAIR to simplify the project−planning process. This strategy helps you avoid the headaches of program planning. STAIR is an acronym for a general problem−solving technique, but that technique is especially well suited for programming problems. STAIR stands for State the problem, Tool identification, Algorithm, Implementation, Refinement. I will explain each of these steps now.

S: State the Problem

The first thing you must do is write down the problem in clear, concise English (or whatever your primary language is). This sounds like the easiest step, but it’s the most difficult. Your statement of the problem should plainly indicate what you want to accomplish—a sentence or paragraph that describes what the program should do. You should avoid the temptation to get technical here. The actual technologies, commands, and syntax are completely irrelevant at this stage. Your grandmother should be able to read and understand your statement of the problem. (Well, if your grandmother happens to be a hotshot programmer, get somebody else to look at your problem statement!) Later in the process, you will become confused, and it will be helpful to have a record somewhere of what you are trying to accomplish. In C#, I like to include my statement of the problem in the actual code as part of the summary.

T: Tool Identification

After you gain a solid understanding of the problem you want to solve, it’s smart to make a list of the tools you will use to solve that problem. Tools can be many things. They can be various commands or objects in the C# language, techniques (such as the random number algorithm I show you in Chapter 2), or structures (such as a while loop). As you gain programming experience, you will learn more tools, and you’ll have more practice applying various tools to programming situations. In this book, the program that begins and ends each chapter is devised to illustrate the tools introduced in the chapter. I usually write the names of variables I will need and any major control structures I will use. The exact order and details of how the tools will be used can wait. Often, I list tools that I don’t end up using. Golfers usually leave the clubhouse with many clubs in their bags. They can’t usually

70

take every club they own, so they select a set of clubs that are likely to be useful for the course they are playing. Identifying tools is a lot like that.

A: Algorithm

After you identify the possible tools, think about your programming strategy. Programmers call a specific programming strategy an algorithm. (Nice sound to it. You have seen by now that programmers love complicated names for simple things.) Now it’s time to think about the order in which you will do things. Some programmers use flowcharts or state diagrams to illustrate how the code is supposed to act. For small programs like those in this book, I usually use a simple list of instructions on paper. By the time you get to the algorithm step, you are actually writing down a form of shorthand to record the kinds of steps you will be taking.

Let me emphasize again that the algorithm should be written down. If you work all this out on paper before you turn on the computer, your programming efforts will be much less painful than if you simply sit down and start banging away.

In the Real World

As you begin to program, no doubt you will run into somebody who is an experienced programmer. Very often, that person will say something like “I never plan my algorithms.” Although many experienced programmers do not use written documentation for their simpler programs, ask them how long it took them to learn and how many mistakes they made when starting. At professional software development houses, programmers are often not allowed to start working on a program until the plan is developed. You don’t have to use STAIR, but if you do not use a scheme to plan your programs before you begin coding, you will run into big problems. If you don’t believe me, try writing programs without a plan and see what happens.

I: Implementation

You might be surprised that none of the first three steps require a computer. The best programming happens far from a computer. I wrote the core of one of my most useful programs on the back of an agenda at a very boring meeting. No computer was in sight, but all the real work could be done with paper and pencil. (Don’t tell my boss about this—he thought I was furiously taking notes about the meeting.)

The implementation stage begins when you turn on the computer and write code. When most people begin programming, they jump directly to this step. (Instead of the STAIR process, they must use the IR process.) If you can succeed by jumping right into the program without planning, that’s fine. Sooner or later, though, you’ll be totally clueless about how to proceed. That’s when you need to back up and think more carefully about the entire problem. Generally, the implementation phase is the easiest part of programming. If your algorithm is written correctly, translating it into working code is a simple matter. If I look at each line of an algorithm and can say, “I know how to do that,” the algorithm is ready for implementation.

Trick Keep your STAIR documentation around. You never know when it will come in handy. I once wrote a program named ABNIAC that simulates a simple machine language computer. I got a chance to demonstrate the program on television, but I had written the program in Visual Basic, which works only on the Windows operating system. The television studio used a Macintosh, so my program would

71