12. The IF Statement

Advanced perspective: decisions create paths to justify

An if statement selects behaviour from current state

An if statement is easy to recognise, but recognition is a poor test of a decision. The real work is to define the states admitted by each condition, the behaviour selected for those states and the evidence that competing branches are excluded where the requirement demands one outcome. Code that reaches the expected branch for one friendly input has proved very little.

The condition is evaluated when control reaches the statement and is contextually converted to bool. If the result is true, the associated statement executes. If it is false, that statement is skipped and an associated else, if present, is selected. Nothing here is probabilistic. The current state and the expression determine the path.

Begin with the value that the condition actually produces

This is why if (x = 0) can be well-formed C++. The assignment changes x to zero, the assignment expression yields a value and that value converts to false. With if (x = 5), x becomes 5 and the condition is true. A compiler warning is valuable evidence that the code deserves inspection, but the repair is not automatically to replace every assignment with equality. First decide whether mutation belongs in the condition at all. If comparison was intended, write ==; if deliberate acquisition or mutation was intended, make that purpose unmistakable.

Independent questions and exclusive choices are different programs

Separate if statements ask separate questions. More than one body may execute. An if, else if, else chain asks for one selection in order; once a condition is true, later conditions in that chain are not evaluated. The two shapes can contain the same predicates and still express different requirements.

If the requirement is to record every property that holds, independent tests may be correct. If the requirement is to assign exactly one grade, the predicates must be ordered or written so that one category is selected. Merely changing if to else if can suppress required behaviour, while leaving independent tests can execute incompatible actions. Syntax follows the decision model.

An else is associated with the nearest preceding unmatched if permitted by the grammar. Indentation does not change that association. Braces make the intended statement boundaries visible and protect the structure when another line is added later. They are cheap evidence against a very expensive misunderstanding.

Predicate order defines the classification

#include <iostream>

const char* describe_health(int health) {
    if (health <= 0) {
        return "defeated";
    }
    if (health < 25) {
        return "critical";
    }
    return "active";
}

int main() {
    std::cout << describe_health(80) << '\n';
    std::cout << describe_health(10) << '\n';
    std::cout << describe_health(0) << '\n';
}

The function contains two separate if statements, yet at most one label is returned. Each successful branch leaves the function immediately, so later tests cannot alter that result. This is a guard-clause form: handle a decisive case, return, then reason about the reduced set of states that remains.

Move health < 25 above health <= 0 and the program still compiles. It also classifies zero and every negative value as critical, because the broader predicate returns before the exceptional case is reached. The order is therefore part of the contract, not a formatting choice.

The table also exposes a requirement question the code cannot answer for us: is negative health a valid state that means defeated, or evidence of an earlier error? The source currently chooses the first policy. If the requirement chooses the second, another outcome and its evidence are needed. Do not smuggle that decision into a test case after the code has already been accepted.

Logical operators are ordered computations

The operators && and || short-circuit from left to right. For left && right, a false left operand decides the whole expression, so the right operand is not evaluated. For left || right, a true left operand decides the expression and the right operand is skipped.

if (pointer != nullptr && *pointer > 0) {
    // Dereference occurs only when the pointer is not null.
}

The first operand is a precondition for the second. If pointer is null, the comparison is false and dereferencing is skipped. Reverse the operands and the dereference is attempted before the null check can protect it. The same facts appear in the expression, but their order changes whether the computation is valid.

Short-circuiting can also skip a function call with side effects. Sometimes that is deliberate, as when acquisition should occur only after validation. Sometimes it hides work a programmer assumed would always happen. Read a compound predicate as an execution trace: which operand runs first, what result admits the next operand and what state may change along the way?

More branches increase obligations, not by a simple formula

It is tempting to count each if and declare that the number of paths has doubled. Real control flow is constrained by returns, mutually exclusive predicates, state dependencies and loops. A branch count can draw attention to complexity, but it cannot replace analysis of reachable states and meaningful outcomes.

Tests should cover the equivalence classes and boundaries created by the predicates. For the health function, -1, 0, 1, 24 and 25 provide stronger evidence than five arbitrary positive values. They exercise both sides of each boundary and the ordering overlap. The ordinary value 80 remains useful, but it does not test the point at which behaviour changes.

Guard clauses can make the same decisions easier to inspect by disposing of failed preconditions early. They do not automatically remove testing obligations or prove equivalence to nested code. For a refactor, trace each original outcome and show that the same input reaches the same effect and return value afterwards. Reduced indentation is a benefit only when behaviour is preserved.

Change the requirement, then earn the new branch

Extend the health requirement so that values above 100 are reported as invalid, while the existing three labels retain their present ranges. Before editing, write the complete decision table for -1, 0, 1, 24, 25, 100 and 101. Decide where the new predicate must appear and explain why a more general predicate cannot consume its state first.

After implementing the change, compile and run those boundary cases. Then replace the guard-clause version with one explicit if, else if, else chain and repeat the table. The task is not to prefer one shape. It is to demonstrate equivalent selection, evaluation order and returned labels. If one row changes, the refactor changed the program, however tidy it looks.

const char* describe_health(int health) {
    if (health > 100) {
        return "invalid";
    }
    if (health <= 0) {
        return "defeated";
    }
    if (health < 25) {
        return "critical";
    }
    return "active";
}

const char* describe_health(int health) {
    if (health > 100) {
        return "invalid";
    } else if (health <= 0) {
        return "defeated";
    } else if (health < 25) {
        return "critical";
    } else {
        return "active";
    }
}