Using Blocks to Group Statements

Nested if statements look simple, but they hide a trap. When one if statement sits inside another and an else follows, it is natural to assume the else belongs to the outer condition you had in mind. The compiler does not read indentation as a rule, though. The structure it builds from the code can differ from the structure you intended, and nothing in the program signals an error when this happens. This gap between intended meaning and actual meaning is called the dangling else problem.

Consider two versions of one nested structure. Both use the same two conditions and the same two print statements. The first version places the inner if directly under the outer if with no block. The second wraps the inner if in curly braces. The only difference between them is how the inner if is grouped.

The general pattern is an opening brace, any number of statements, and a closing brace. Each pair of braces marks one block. The braces, not the line breaks, mark where a group begins and ends. In a block with two print statements, both statements sit between the same pair of braces, so together they form a single unit that can be treated as one thing.

A block with no statements is still legal. The source says an empty block can be useful at times without listing specific uses, so treat an empty pair of braces as a legal, meaningful form you will recognize when you see it. Its legality follows from the general rule that a block can occur wherever a statement can occur.

Blocks usually appear inside other statements, where their purpose is to group several statements so they can be treated as one unit. A block can legally be used anywhere a single statement is allowed, which means a block is itself a kind of statement. Because of this, blocks can be nested inside one another.

There is one place where a block is required rather than merely allowed. The definition of a subroutine is a block, because it is a sequence of statements enclosed inside a pair of braces. The main subroutine of a program is the example the source uses. Whatever statements belong to the subroutine go inside its braces.

The swap block is a good place to practice tracing. It uses a helper variable called temp, and each line changes one variable, so the order of the lines matters. The following block swaps the values of x and y. The starting state, x equal to 3 and y equal to 7, is generated for this walkthrough and is not from the source.

Now notice what happens when the order changes. Suppose the first two lines were reversed, so that x = y ran before temp = x. The original value of x would be lost before it was saved. The trace then looks like this: x becomes 7, temp is assigned the new x which is 7, and y is assigned temp which is 7. Both variables end up holding 7, and the swap has failed. This is the spot to look when a trace goes wrong: the step where the expected value first differs from the actual one.

The source states that declaring a variable inside a block is legal, and that it is good style to do so when the variable is used nowhere else but inside the block. The temp variable in the swap example is exactly this case. It exists only to help with the swap, so it is declared inside the swap block. Code outside that block cannot see temp, even though the enclosing subroutine body can see the swap block itself.

Return to the two versions from the opening. The first version has no block. Without a block, the outer if controls only the single statement immediately after it, which is the inner if. The else that follows is then read against that inner statement, so it pairs with the inner condition y greater than zero rather than the outer condition x greater than zero. In this reading, the outer if has no else at all.

Adding a block changes the grouping. The braces enclose the inner if so that it becomes one unit inside the outer if. The else that follows the closing brace can no longer attach to the inner statement, so it pairs with the outer condition. The source gives this as the fix: enclosing the nested if in a block forces the reading the programmer usually intends.

Java is a free-format language. There are no syntax rules about how a program must be arranged on a page, so the same block can be written on one line or spread across many, and both forms are legal. Good style, however, lays out the program so its structure is as clear as possible. The general rule the source gives is to put one statement per line and to use indentation to show statements contained inside control structures.