not run. Fortunately, I still had the algorithm on paper. Translating the program from one language to another turned out to be a simple task because the underlying algorithm hadn’t changed. (Java runs fine on Macs.) I had already done the hard work of creating an algorithm, so implementing that algorithm again in a new language was all that needed to be done.

R: Refinement

With all this planning, you might expect your program to run correctly the first time. It won’t. Even experienced professional programmers expect their programs to crash many times. A lot can go wrong. Keep a positive attitude or else you’ll get discouraged. When your program does not work, it usually gives you clues about what is wrong. Sometimes it crashes and gives you an error message. Although this seems bad, it’s a good thing because you get lots of information about what has gone wrong. The error messages in C# are reasonably clear, and the editor brings you back to the spot where the interpreter noticed the mistake. These tools can be very helpful in spotting your problems.

In the Real World

The conception of the STAIR acronym is a good example of the problem−solving process. I was working with a team of computer science instructors who agreed that we did not have an effective way to teach problem−solving strategies to beginning programmers. We mulled over the principles for days. Although we all agreed on the basic framework, we couldn’t figure out how to make it easy to remember and use. The next week, I had a dream about climbing stairs while writing a program, and I suddenly woke up. My wife remembers that I sat up and said, “That’s it!!” Then I wrote the acronym STAIR on the paper I keep beside my bed. (This wasn’t the first time an idea had occurred to me in a dream.)

Although the principles are not at all new, the acronym for thinking about them was an innovation that is now used by many programmers. Perhaps the real lesson is that sometimes your best thinking happens when you aren’t trying. Take a break once in a while, and let your mind catch up. Maybe you, too, should keep a pad of paper by your bed.

As a general strategy for refining your program, look back at the STAIR steps again. Did you state the problem correctly? Did you miss a tool that might automatically solve your problem, or did you use a tool incorrectly? Did you define a solid algorithm that will help you solve the problem correctly? Did you implement correctly? Maybe you made a typing error or missed a quotation mark, something silly like that. (In fact, the problems that cause the greatest grief are usually silly, such as a period where a comma should go, misspelled variable names, and the like.)

Applying STAIR to the Pig Latin Program

The STAIR concept is nice in an academic sort of way, but its real power comes when you try to solve a problem of any complexity. To illustrate this, imagine trying to write the Pig Latin program right now, before you finish the chapter. You have all the tools you need, but you don’t have a plan. I suspect that it would be a frustrating exercise. Use the STAIR process to set up a plan for your program. This makes the programming experience much more pleasant.

72

Stating the Problem

The following paragraph explains how I thought about this problem.

Create a program that demonstrates string manipulation and looping structures. The program should ask the user for a phrase and then translate that phrase into pig latin. The program should break the phrase into words and then look at the first character of each word. If the initial character is a vowel, the program should simply add way to the end of the word. If the first character is a consonant, the program should remove that consonant from the beginning of the word, add the consonant to the end of the word, and add ay after the consonant. The program should then ask for another phrase. When the user types quit as the phrase, the program should exit.

Notice how complete and well thought out this statement of the problem is. It could still be improved, but it’s a good starting place. Writing a program from a statement like this is much easier than from one that simply states, “Make a Pig Latin program.”

Identifying the Tools

This program is likely to need the following tools:

∙A while loop to control continuing the program until the user enters quit

∙Some type of input to get the phrase from the user

∙A foreach...split structure to break the phrase into words

∙A variable to hold each word (word)

∙The String.SubString() method to divide the word into first character and other characters

∙Variables for the first character (firstChar) and the rest of the word (restOfWord)

∙A condition to see whether the first character is a vowel

∙A WriteLine statement to send the completed pig latin phrase to the screen

Other tools might be necessary, but this list will do as a starting point. In essence, I built this list by looking again at the statement of the problem and looking at the kinds of tools I anticipate using to solve the various little problems along the way.

Creating the Algorithm

The algorithm works by restating the problem in terms of the tools. At this point, I usually do two things: I try to get the statements in the correct order, and I begin to flesh out some of the details. This results in a stylistic language that is neither English nor a programming language. It’s frequently called pseudocode by people who name such things. Although there are some formal definitions for pseudocode, I generally write short statements that I know I’ll be able to translate into the language I’m writing in. Here’s my first crack at pseudocode for the Pig Latin program: (Note that in this book, pseudocode will be in italics):

Pseudocode:

Create variables, word, firstChar, restOfWord, sentence, pigWord

while user has not said "quit"

ask user for sentence

look at sentence one word at a time (foreach)

73