0.3.4 Understanding True/False Values

Some Information Has Only Two States

Many program decisions depend on information that can be answered with one of two values:

• true
• false

This kind of value is called a Boolean value.

A Boolean does not mean “good” or “bad.” It represents whether a specific statement or condition is true.

For a soccer system, examples might include:

• Is the player available?
• Has the match started?
• Is the field open?
• Is the team registered?

Each question can be represented with a true/false value.

The Meaning Comes From the Question

The value true is not meaningful by itself.

Consider:

true

True about what?

Now give it a name:

isAvailable = true

The meaning becomes much clearer.

Read it as:

The statement “the player is available” is true.

Likewise:

isAvailable = false

means:

The statement “the player is available” is false.

A good Boolean name helps the value read like a yes/no question.

Positive Names Are Easier to Read

Compare these two names:

isAvailable

and:

isNotUnavailable

Both could technically represent a true/false state, but the second requires more mental work.

For:

isAvailable = true

the meaning is direct.

For:

isNotUnavailable = false

you have to untangle two negatives before you know what the state means.

When you read Boolean information, translate the name and value into a simple sentence.

Boolean State Can Change

Suppose a soccer player begins the week as available.

isAvailable = true

Later, the player reports that they cannot attend.

isAvailable = false

The player object can remain the same object.

One part of its state changed.

That connects Boolean values to the object-state ideas you learned earlier.

A Boolean Can Control Which Path Makes Sense

Consider this process:

If the player is available, include the player in the available-player list.

The important information is the condition:

Is the player available?

If the answer is true, one action makes sense.

If the answer is false, that action should not occur.

You are not writing C# decision statements yet.

For now, focus on the reasoning:

A Boolean condition can determine which path a process follows.

True and False Are Values, Not Text Labels

In a technical model, there is a difference between a Boolean value:

true

and the text:

"true"

The first represents a true/false state.

The second is text containing the letters t-r-u-e.

At this stage, the important idea is simply to recognize that Boolean state is a distinct kind of information.

The same distinction will matter later when you work more directly with C# data types.

Boolean Questions Should Be Specific

Consider:

isGood = true

What does “good” mean?

Is the player good?

Is the weather good?

Is the field condition good?

A Boolean is more useful when the statement being evaluated is specific.

For example:

• isAvailable
• hasStarted
• isFieldOpen

Clear names make later decisions easier to understand.

A Condition Can Be Read as a Question

When you encounter a Boolean condition, turn it into a yes/no question.

For:

isAvailable

ask:

Is the player available?

For:

hasStarted

ask:

Has the match started?

For:

isFieldOpen

ask:

Is the field open?

That habit becomes especially useful when you begin reading decision nodes in UML activity diagrams.

From State to Flow

Until now, you have often looked at information as state:

player1 : Player
-------------------------
isAvailable = true

Now that same value can influence process flow.

If isAvailable is true, one action may occur.

If it is false, another path may be followed.

That is the bridge between Boolean state and decision-making.

The next activities show how UML activity diagrams represent those paths visually.