ترويض الشروط المتداخلة

Written Explanation

Why deep nesting hurts

Each nesting level adds a fact you must hold in your head: "I am here only if A is true, and B is true, and...". Three levels deep, the actual action sits far from the conditions that lead to it, and the else branches are scattered at the bottom, far from the if they belong to. Beginners add a level for every new rule. Experienced developers ask how to remove one.

Tool 1: combine with && and ||

Two nested if statements with no else between them are the same as one if with &&:

// nested
if (a) {
    if (b) {
        run();
    }
}
// equivalent
if (a && b) {
    run();
}

The first version runs run() only when a is true and, inside that, b is true. Both must hold, which is exactly &&. Because && is short-circuit, b is not even evaluated when a is false, so you can safely write x != 0 && 10 / x > 2.

Use || when several different conditions lead to the same action: if (isMember || hasCoupon). Mix them with parentheses, because && binds tighter than ||.

This tool works when all the cases lead to the same action. It does not help when each failed test needs its own message, as in the next tool.

Tool 2: early exits (guard clauses)

When each condition has a different failure message, deal with the failures first and leave the normal path at the end. This is called an early exit or guard clause: test for the bad case, report it, and leave.

In a method you leave with return. You have not met methods yet (they start in a later module), but main is a method, and a return; inside it simply ends the program. We use that here for the pattern; the same style carries over into every method you will write later.

The shape:

if (badCase1) { report; return; }
if (badCase2) { report; return; }
// all checks passed: normal work here

The normal path sits at the lowest indentation, and every check is one line away from its message. Compare this with the nested version in Example 3.

Tool 3: name the condition

A long test is easier to read when each part has a name:

boolean isSenior = age >= 65;
boolean isChild = age < 12;
boolean discountEligible = member && (isSenior || isChild);
if (discountEligible) { ... }

A reader now sees the rule, not the arithmetic. A named variable also gives you somewhere to put a comment and a place to print while debugging.

How else pairs when braces are missing

An else always belongs to the nearest unmatched if before it. With braces this is obvious; without them, your indentation can lie. Example 2 shows it. Another reason for the "always use braces" rule from Lesson 1.

Auditing conditions: unreachable and overlapping branches

When you finish a decision, check every pair of branches.

• Unreachable branch: a branch that can never run because earlier tests catch every value that could reach it. In if (x > 5) {...} else if (x > 10) {...}, any x above 10 is already above 5, so the second block is dead code.
• Overlap: two conditions that can be true for the same value. In a chain the earlier one wins silently; in separate if statements both run. Either way, the author probably did not mean it.
• Gap: a value that no branch handles (Lesson 2).

Java's compiler does not warn about these logic errors, even though the dead code is easy to see. (It does reject statements that are provably unreachable in specific structural ways, such as code after return, but not an if branch whose condition happens to be impossible.) The only defence is to test: for each branch, find an input that reaches it. If you cannot find one, the branch is dead.