1.4.28 Debugging Boolean Expressions

The Debugger Can Show Why a Condition Follows One Path

An if statement depends on a Boolean result.

For example:

if (score >= 3)
{
    System.Console.WriteLine("Three or more goals.");
}

When debugging, you can inspect the values that make the condition true or false.

This helps answer:

Pause Before the Decision

Set a breakpoint before or at the decision statement.

Suppose the current code is:

if (score >= 3)

Before stepping, inspect:

score

If the debugger shows:

score = 2

you can predict:

2 >= 3 → false

The controlled block should be skipped.

Predict Before Pressing F10

A useful debugging habit is:

Activity diagram showing inspect values, then evaluate condition yourself, then predict path, then step, then compare actual path with prediction.
InspectValues.
  • New
  • Changed
  • Removed

Do not use the debugger only as a way to discover what happened after the fact.

Use it to test your reasoning.

Debug an Equality Expression

Suppose:

if (player1.position == "Goalkeeper")

Inspect:

player1.position

If the current value is:

"Forward"

predict:

"Forward" == "Goalkeeper" → false

Then step and observe whether the block is skipped.

Debug a Null Check

Suppose:

if (player1.team == null)

Inspect:

player1.team

If the debugger shows:

null

then the condition should evaluate to true.

If the debugger shows an expandable Team object, the condition should evaluate to false.

Debug the Not Operator in Stages

Consider:

if (!player1.isAvailable)

If the debugger shows:

player1.isAvailable = false

evaluate:

false

then apply:

!

to get:

true

The block should run.

Debug a Relational Comparison

For:

if (distanceToBall < 5.0)

inspect:

distanceToBall

If:

distanceToBall = 4.5

then:

4.5 < 5.0 → true

If the block does not behave as predicted, re-check:

  • the current value;
  • the operator;
  • the source line;
  • the execution point.
The Source Location Matters

If execution pauses before a previous assignment, the variable may not yet have the value you expected.

For example:

distanceToBall = 4.5;
if (distanceToBall < 5.0)

If you pause before the assignment executes, the debugger may show an earlier value.

Always ask:

Inspect the Inputs to the Expression

The current debugger tools can show:

  • fields;
  • parameters;
  • local variables;
  • object references.

You do not need to guess which value an expression is using.

Inspect the values that feed the condition.

A Boolean Expression Can Be Correct While the Input Is Wrong

Suppose:

if (score >= 3)

is logically correct.

But the debugger shows:

score = 1

when the requirement expected 4.

The defect may be in an earlier calculation or assignment rather than in the if statement.

The condition evaluates the state it receives.

Write a Precise Explanation

A strong debugging explanation sounds like:

That explanation connects:

  • runtime value;
  • Boolean expression;
  • Boolean result;
  • execution path.
The Main Debugging Pattern

For every conditional expression:

  1. identify the values used;
  2. inspect those values at the correct execution point;
  3. evaluate the expression;
  4. predict true or false;
  5. step through the statement;
  6. compare the observed path with the prediction.

That process turns conditional debugging into evidence-based reasoning.