Looking carefully at if statements

An if statement can take the following form:

if (Condition) {
SomeStatements
} else {
OtherStatements
}

To get a real-life if statement, substitute meaningful text for the three placeholders Condition, SomeStatements, and OtherStatements. Here’s how I make the substitutions in Listing 9-1:

• I substitute randomNumber > 5 for Condition.
• I substitute System.out.println("Yes. Isn’t it obvious?"); for SomeStatements.
• I substitute System.out.println("No, and don’t ask again."); for OtherStatements.

The substitutions are illustrated in Figure 9-3.

Sometimes I need alternate names for parts of an if statement. I call them the if clause and the else clause:

if (Condition) {
if clause
} else {
else clause
}

An if statement is an example of a compound statement — a statement that includes other statements within it. The if statement in Listing 9-1 includes two println calls, and these calls to println are statements.

Notice how I use parentheses and semicolons in the if statement of Listing 9-1. In particular, notice the following:

• The condition must be in parentheses.
• Statements inside the if clause end with semicolons. So do statements inside the else clause.
• There’s no semicolon immediately after the condition.
• There’s no semicolon immediately after the word else.

As a beginning programmer, you may think these rules are arbitrary. But they’re not. These rules belong to a carefully crafted grammar. They’re like the grammar rules for English sentences, but they’re even more logical! (Sorry, Becky.)

Table 9-1 shows you the kinds of things that can go wrong when you break the if statement’s punctuation rules. The table’s last two items are the most notorious. In these two situations, the compiler doesn’t catch the error. This lulls you into a false sense of security. The trouble is, when you run the program, the code’s behavior isn’t what you expect it to be.

As you compose your code, it helps to think of an if statement as one indivisible unit. Instead of typing the whole first line (condition and all), try typing the if statement’s skeletal outline:

if () { //To do: Fill in the condition.
//To do: Fill in the if clause.
} else {
//To do: Fill in the else clause.
}

With the entire outline in place, you can start working on the items on your to-do list. When you apply this kind of thinking to a compound statement, it’s harder to make a mistake.

A complete program

Listing 9-2 contains a complete program with a simple if statement. The listing’s code behaves like an electronic oracle. Ask the program a yes-or-no question, and the program answers you back. Of course, the answer to your question is randomly generated. But who cares? It’s fun to ask anyway.

LISTING 9-2 I Know Everything

import java.util.Scanner;
import java.util.Random;

class AnswerYesOrNo {

public static void main(String args[]) {
Scanner keyboard = new Scanner(System.in);
Random myRandom = new Random();
int randomNumber;

System.out.print("Type your question, my child: ");
keyboard.nextLine();

randomNumber = myRandom.nextInt(10) + 1;

if (randomNumber > 5) {
System.out.println("Yes. Isn’t it obvious?");
} else {
System.out.println("No, and don’t ask again.");
}

keyboard.close();
}
}

Figure 9-4 shows several runs of the program in Listing 9-2. The program’s action has four parts:

1. Prompt the user.

   Call  System.out.print, telling the user to type a question.

2. Get the user’s question from the keyboard.

   In Figure 9-4, I run the AnswerYesOrNo program four times, and I type a different question each time. Meanwhile, back in Listing 9-2, the statement

   keyboard.nextLine();

   swallows up my question and does absolutely nothing with it. This is an anomaly, but you’re smart, so you can handle it.

   Normally, when a program gets input from the keyboard, the program does something with the input. For example, the program can assign the input to a variable:

   amount = keyboard.nextDouble();

   Alternatively, the program can display the input on the screen:

   System.out.println(keyboard.nextLine());

   But the code in Listing 9-2 is different. When this AnswerYesOrNo program runs, the user has to type something. (The call to nextLine waits for the user to type some stuff and then press Enter.) But the AnswerYesOrNo program has no need to store the input for further analysis. (The computer does what I do when my wife asks me whether I plan to clean up after myself — I ignore the question and make up an arbitrary answer.) So the program doesn’t do anything with the user’s input. The call to keyboard.nextLine just sits there in a statement of its own, doing nothing, behaving like a big, black hole. It’s unusual for a program to do this, but an electronic oracle is an unusual thing. It calls for some slightly unusual code.

3. Get a random number — any int value from 1 to 10.

   Okay, wise guys. You’ve just trashed the user’s input. How will you answer yes or no to the user’s question?

   No problem! None at all! You’ll display an answer randomly. The user won’t know the difference. (Ha ha!) You can do this as long as you can generate random numbers. The numbers from 1 to 10 will do just fine.

   In Listing 9-2, the stuff about Random and myRandom looks much like the familiar Scanner code. From a beginning programmer’s point of view, Random and Scanner work almost the same way. Of course, there’s an important difference: A call to the Random class’s nextInt(10) method doesn’t fetch anything from the keyboard. Instead, this nextInt(10) method gets a number out of the blue.

   The name Random is defined in the Java API. The call to myRandom.nextInt(10) in Listing 9-2 gets a number from 0 to 9. Then my code adds 1 (making a number from 1 to 10) and assigns that number to the variable randomNumber. When that’s done, you’re ready to answer the user’s question.

   In Java’s API, the word Random is the name of a Java class, and nextInt is the name of a Java method. For more information on the relationship between classes and methods, see Chapters 17, 18, and 19.

4. Answer yes or no.

   Calling myRandom.nextInt(10) is like spinning a wheel on a TV game show. The wheel has slots numbered 1 to 10. The if statement in Listing 9-2 turns your number into a yes-or-no alternative. If you roll a number that’s greater than 5, the program answers yes. Otherwise (if you roll a number that’s less than or equal to 5), the program answers no.

   You can trust me on this one. I’ve made lots of important decisions based on my AnswerYesOrNo program.

Indenting if statements in your code

Notice how, in Listing 9-2, the println calls inside the if statement are indented. Strictly speaking, you don’t have to indent the statements that are inside an if statement. For all the compiler cares, you can write your whole program on a single line or place all your statements in an artful, misshapen zigzag. The problem is, if you don’t indent your statements in some logical fashion, neither you nor anyone else can make sense of your code. In Listing 9-2, the indenting of the println calls helps your eyes (and brain) see quickly that these statements are subordinate to the overall if/else flow.

In a small program, unindented or poorly indented code is barely tolerable. But in a complicated program, indentation that doesn’t follow a neat, logical pattern is a big, ugly nightmare.

Always indent your code to make the program’s flow apparent at a glance.

You don’t have to think about indenting your code, because Eclipse can indent your code automatically. For details, see Chapter 4.

… Or else what?

You can create an if statement without an else clause. For example, imagine a web page on which one in ten randomly chosen visitors receives a special offer. To keep visitors guessing, I call the Random class’s nextInt method and make the offer to anyone whose number is lucky 7:

• If myRandom.nextInt(10) + 1 generates the number 7, display a special offer message.
• If myRandom.nextInt(10) + 1 generates any number other than 7, do nothing. Don’t display a special offer message and don’t display a discouraging, “Sorry, no offer for you,” message.

The code to implement such a strategy is shown in Listing 9-3. A few runs of the code are shown in Figure 9-5.

LISTING 9-3 Aren’t You Lucky?

import java.util.Random;

class SpecialOffer {

public static void main(String args[]) {
Random myRandom = new Random();
int randomNumber = myRandom.nextInt(10) + 1;

if (randomNumber == 7) {
System.out.println("An offer just for you!");
}
System.out.println(randomNumber);
}
}

The if statement in Listing 9-3 has no else clause. This if statement has the following form:

if (Condition) {
SomeStatements
}

When randomNumber is 7, the computer displays An offer just for you! When randomNumber isn’t 7, the computer doesn’t display An offer just for you! The action is illustrated in Figure 9-6.

Always (I mean always) use a double equal sign when you compare two numbers or characters in an if statement’s condition. Never (that’s never, ever, ever) use a single equal sign to compare two values. A single equal sign does assignment, not comparison.

In Listing 9-3, I took the liberty of adding an extra println. This println (at the end of the main method) displays the random number generated by my call to nextInt. On a web page with special offers, you probably wouldn’t see the randomly generated number, but I can’t test my SpecialOffer code without knowing what numbers the code generates.

Anyway, notice that the value of randomNumber is displayed in every run. The println for randomNumber isn’t inside the if statement. (This println comes after the if statement.) So the computer always executes this println. Whether randomNumber == 7 is true or false, the computer takes the appropriate if action and then marches on to execute System.out.println(randomNumber).

Packing more stuff into an if statement

Here’s an interesting situation: You have two baseball teams — the Hankees and the Socks. You want to display the teams’ scores on two separate lines, with the winner’s score coming first. (On the computer screen, the winner’s score is displayed above the loser’s score. In case of a tie, you display the two identical scores, one above the other.) Listing 9-4 has the code.

LISTING 9-4 May the Best Team Be Displayed First

import java.util.Scanner;
import static java.lang.System.in;
import static java.lang.System.out;

class TwoTeams {

public static void main(String args[]) {
Scanner keyboard = new Scanner(in);
int hankees, socks;

out.print("Hankees and Socks scores? ");
hankees = keyboard.nextInt();
socks = keyboard.nextInt();
out.println();

if (hankees > socks) {
out.print("Hankees: ");
out.println(hankees);
out.print("Socks: ");
out.println(socks);
} else {
out.print("Socks: ");
out.println(socks);
out.print("Hankees: ");
out.println(hankees);
}

keyboard.close();
}
}

Figure 9-7 has a few runs of the code. (To show a few runs in one figure, I copied the results from Eclipse’s Console view to Windows Notepad.)

With curly braces, a bunch of print and println calls are tucked away safely inside the if clause. Another group of print and println calls are squished inside the else clause. This creates the forking situation shown in Figure 9-8.

Some handy import declarations

When I wrote this section’s example, I was tired of writing the word System. After all, Listing 9-4 has ten System.out.print lines. By this point in the book, shouldn’t my computer remember what out.print means?

Of course, computers don’t work that way. If you want a computer to “know” what out.print means, you have to code that knowledge somewhere inside the Java compiler.

Fortunately for me, the ability to abbreviate things like System.out.print is available from Java 5.0 onward. (An older Java compiler simply chokes on the code in Listing 9-4.) This ability to abbreviate things is called static import. It’s illustrated in the second and third lines of Listing 9-4.

Whenever I start a program with the line

import static java.lang.System.out;

I can replace System.out with plain out in the remainder of the program. The same holds true of System.in. With an import declaration near the top of Listing 9-4, I can replace new Scanner(System.in) with the simpler new Scanner(in).

You may be wondering what all the fuss is about. If I can abbreviate java.util.Scanner by writing Scanner, what’s so special about abbreviating System.out? And why do I have to write out.print? Can I trim System.out.print to the single word print? Look again at the first few lines of Listing 9-4. When do you need the word static? And what’s the difference between java.util and java.lang?

I’m sorry. My response to these questions won’t thrill you. The fact is, I can’t explain away any of these issues until Chapter 18. Before I can explain static import declarations, I need to introduce some ideas. I need to describe classes, packages, and static members.

Until you reach Chapter 18, please bear with me. Just paste three import declarations to the top of your Java programs and trust that everything will work well.

You can abbreviate System.out with the single word out. And you can abbreviate System.in with the single word in. Just be sure to copy the import declarations exactly as you see them in Listing 9-4. With any deviation from the lines in Listing 9-4, you may get a compiler error.

Get some practice writing if statements!