1.5.13 Debugging if and if/else Statements

When a decision behaves unexpectedly, first identify:

Then use the debugger to compare your prediction with the actual execution path.

Consider:

if (player1.isAvailable)
{
    System.Console.WriteLine("Available");
}
else
{
    System.Console.WriteLine("Unavailable");
}

Pause before or on the decision and inspect:

player1.isAvailable

Suppose it is:

false

Predict:

if block → skipped
else block → runs

Then step through the decision.

For:

if (player1.position == "Goalkeeper")

inspect:

player1.position

If the debugger shows:

"Forward"

predict:

"Forward" == "Goalkeeper" → false

The true block should be skipped.

Suppose:

if (team1.score >= 3)

Check important values:

2 >= 3 → false
3 >= 3 → true
4 >= 3 → true

If the code behaves incorrectly at the boundary, inspect whether the operator matches the requirement.

For:

if (player1.team == null)

inspect:

player1.team

If it shows:

null

predict true.

If it shows an actual Team object, predict false.

Use F10 / Step Over.

For a basic if/else:

condition true  → enter if block
condition false → enter else block

The highlighted source path provides runtime evidence.

Suppose you expected:

score = 3

but the debugger shows:

score = 0

The defect may occur before the if.

Ask:

A correct condition can still choose the wrong path if its input state is wrong.

Consider:

if (player1.isAvailable)
{
    System.Console.WriteLine("Unavailable");
}
else
{
    System.Console.WriteLine("Available");
}

If:

isAvailable = true

the debugger correctly enters the if block.

The condition is working.

The branch action is wrong.

Debugging means comparing both the path and the action with the requirement.

Suppose:

player1.DisplayStatus(false);

calls:

public void DisplayStatus(bool available)
{
    if (available)
    {
        System.Console.WriteLine("Available");
    }
    else
    {
        System.Console.WriteLine("Unavailable");
    }
}

Trace:

argument false
   ↓
parameter available = false
   ↓
condition = false
   ↓
else block

The debugger can confirm each stage.

If the condition is inside a method, the Call Stack can help identify which caller brought execution there.

That matters when the same method can be called from several places with different arguments.

Avoid random edits.

A stronger process is:

read requirement
   ↓
inspect runtime values
   ↓
evaluate condition
   ↓
predict branch
   ↓
step through
   ↓
compare observed behavior
   ↓
correct the specific defect