Branching

Branching is a simple concept, but it’s powerful. In fact, it’s so simple that I bet I don’t even have to explain it at all; I’ll just show you:

But if we put in a different name…

And that is branching. If what comes after the if is true, we run the code between the if and the end. If what comes after the if is false, we don’t. Plain and simple.

I indented the code between the if and the end just because I think it’s easier to keep track of the branching that way. Almost all programmers do this, regardless of what language they are programming in. It may not seem that helpful in this simple example, but when programs get more complex, it makes a big difference. Often, when people send me programs that don’t work but they can’t figure out why, it’s something that is both:

• obvious to see what the problem is if the indentation is nice, and

• impossible to see what the problem is otherwise.

So, try to keep your indentation nice and consistent. Have your if and end line up vertically, and have everything between them indented. I use an indentation of two spaces.

Often, we would like a program to do one thing if an expression is true and another if it is false. That’s what else is for.

Now let’s try a different name:

And one more:

Branching is kind of like coming to a fork in the code: do we take the path for people whose name == 'Chris', or else do we take the other, less fortuitous, path? (Well, I guess you could also call it the path of fame, fortune, and glory. But it’s my fortune-teller, and I say it’s less fortuitous. So there.) Clearly, branching can get pretty deep.

Just like the branches of a tree, you can have branches that themselves have branches, as we can see on the next page.

Fine, I’ll capitalize my name:

Sometimes it might get confusing trying to figure out where all the ifs, elses, and ends go. What I do is write the end at the same time I write the if. So, as I was writing the previous program, this is how it looked first:

Then I filled it in with comments, stuff in the code the computer will ignore:

Anything after a # is considered a comment (unless, of course, the # is in a string). After that, I replaced the comments with working code. Some people like to leave the comments in; personally, I think well-written code usually speaks for itself. (The trick, of course, is in writing well-written code.) I used to use more comments, but the more “fluent” in Ruby I become, the less I use them. I actually find them distracting much of the time. It’s a personal choice; you’ll find your own (usually evolving) style.

Anyway, my next step looked like this:

Again, I wrote the if, else, and end all at the same time. It really helps me keep track of “where I am” in the code. It also makes the job seem easier because I can focus on one small part, such as filling in the code between the if and the else. The other benefit of doing it this way is that the computer can understand the program at any stage. Every one of the unfinished versions of the program I showed you would run. They weren’t finished, but they were working programs. That way I could test them as I wrote them, which helped me see how my program was coming along and where it still needed work. When it passed all the tests, I knew I was done.

I strongly suggest you approach your programs in this way. These tips will help you write programs with branching, but they also help with the other main type of flow control.