C# Booleans: Turn Clear Requirements into Correct Rules

What you will understand

• Use bool values and meaningful positive condition names.
• Derive decisions from comparisons without confusing a flag with an action.
• Distinguish mandatory AND requirements from inclusive OR alternatives.
• Control the scope of negation and verify equivalent range checks.
• Explain why stored conditions do not track later source changes.
• Keep dependent text and numeric checks behind appropriate guards.
• Distinguish an unknown bool? answer from explicit false.
• Find counterexamples and test each gate and boundary independently.

Use bool for a clearly named yes-or-no fact

A Boolean value is true or false. A good Boolean name makes the question visible: lessonOpen, accountActive or quantityAllowed. When you read the name in a condition, it should describe something that can be answered without guessing what a numeric flag means.

C# does not implicitly interpret a nonzero number or a nonempty string as true. The literals true and false are different from the text "true" and "false". If another system supplies text or numbers, interpret and validate that representation at the boundary before relying on it.

You have already used logical operators and input guards. This lesson focuses on translating a complete written rule into a readable decision, then checking that no alternative route bypasses a mandatory requirement. Each editor is a complete separate program. One example intentionally fails compilation to illustrate the type boundary.

using System;

bool registrationOpen = true;
bool soldOut = false;
Console.WriteLine($"Registration open: {registrationOpen}");
Console.WriteLine($"Sold out: {soldOut}");
Console.WriteLine($"Not sold out: {!soldOut}");

Select Run code to compile and execute this program.

Registration open: True
Sold out: False
Not sold out: True

using System;

bool enabled = 1;
Console.WriteLine(enabled);

Select Run code to compile and execute this program.

Compilation fails: int is not implicitly convertible to bool.

Separate source facts from the decision they support

Some facts arrive as flags; others are derived from comparisons. requested > 0 asks whether a quantity is positive. requested <= available asks whether it fits current stock. Both expressions produce bool, and neither changes the underlying quantities.

Name a condition when the name explains its role in the rule. positiveRequest and fitsStock make canSupply easier to review than a crowded output expression. Avoid names that promise more than the check establishes: a prefix match does not prove a valid identifier, and a nonblank name does not prove identity.

A stored Boolean is evaluated when assigned. It does not remain linked to its source values. If source state changes, reconsider or recompute the decision at its point of use. The snapshot example makes that behavior explicit; concurrency and authoritative validation remain responsibilities of an actual application.

using System;

int requested = 4;
int available = 4;
bool positiveRequest = requested > 0;
bool fitsStock = requested <= available;
bool canSupply = positiveRequest && fitsStock;
Console.WriteLine($"Positive request: {positiveRequest}");
Console.WriteLine($"Fits stock: {fitsStock}");
Console.WriteLine($"Can supply: {canSupply}");

Select Run code to compile and execute this program.

Positive request: True
Fits stock: True
Can supply: True

using System;

int available = 1;
bool hasStock = available > 0;
available = 0;
Console.WriteLine($"Available now: {available}");
Console.WriteLine($"Stored flag: {hasStock}");
hasStock = available > 0;
Console.WriteLine($"Recomputed flag: {hasStock}");

Select Run code to compile and execute this program.

Available now: 0
Stored flag: True
Recomputed flag: False

Distinguish all requirements from alternative routes

Use AND when every named requirement must be true. A complete form may need a name, an allowed quantity and an open submission window. A failure of any mandatory condition makes the decision false, regardless of how many other checks passed.

Use inclusive OR when at least one route is sufficient. A member or a coupon holder may qualify for the example benefit, including someone with both. Exactly one is a different rule; do not accidentally exclude the both-true case when alternatives are meant to be inclusive.

Write the policy in words before choosing symbols. Identify the mandatory gates and group each set of alternatives separately. Then test each fact changing from true to false while the others stay valid. This is more revealing than testing only an ordinary all-true example.

using System;

bool namePresent = true;
bool quantityAllowed = true;
bool formOpen = false;
bool canSubmit = namePresent && quantityAllowed && formOpen;
Console.WriteLine($"Can submit: {canSubmit}");

Select Run code to compile and execute this program.

Can submit: False

using System;

bool member = true;
bool coupon = true;
bool discountEligible = member || coupon;
Console.WriteLine($"Eligible: {discountEligible}");

Select Run code to compile and execute this program.

Eligible: True

using System;

bool member = true;
bool invited = false;
bool registrationOpen = false;
bool misleading = member || invited && registrationOpen;
bool intended = (member || invited) && registrationOpen;
Console.WriteLine($"Without grouping: {misleading}");
Console.WriteLine($"With shared gate: {intended}");

Select Run code to compile and execute this program.

Without grouping: True
With shared gate: False

Negating one fact is different from negating a complete rule

Prefix ! reverses a Boolean result. Parentheses control its scope. !member || invited negates only the membership flag; !(member || invited) asks whether neither route is present. Read the parenthesized question first, then reverse its answer.

De Morgan’s rules help check a rewritten condition: not (a and b) means not a or not b; not (a or b) means not a and not b. You do not need to rewrite every condition this way, but the equivalence helps distinguish at least one missing requirement from all requirements missing.

Range checks provide a concrete example. Inside an inclusive interval means at least the minimum and at most the maximum. Outside means below the minimum or above the maximum. Test the endpoints and neighboring values, and check that inside and outside are opposite answers for this ordered integer interval.

using System;

bool hasName = true;
bool hasQuantity = false;
bool incomplete = !(hasName && hasQuantity);
bool equivalent = !hasName || !hasQuantity;
bool neitherPresent = !hasName && !hasQuantity;
Console.WriteLine($"Incomplete: {incomplete}");
Console.WriteLine($"Equivalent check: {equivalent}");
Console.WriteLine($"Neither present: {neitherPresent}");

Select Run code to compile and execute this program.

Incomplete: True
Equivalent check: True
Neither present: False

using System;

int quantity = 0;
bool inside = quantity >= 1 && quantity <= 6;
bool outside = quantity < 1 || quantity > 6;
Console.WriteLine($"Inside: {inside}");
Console.WriteLine($"Outside: {outside}");
Console.WriteLine($"Opposite answers: {outside == !inside}");

Select Run code to compile and execute this program.

Inside: False
Outside: True
Opposite answers: True

Keep dependent checks behind the condition that makes them meaningful

Short-circuiting is part of a rule’s execution, not just its final truth value. && skips its right operand when the left is false, while || skips it when the left is true. A presence check must run before a string instance method that needs a present value.

Parsing introduces a different dependency. A result slot is meaningful as supplied numeric input only when parsing succeeded. Include the parse flag in the final condition before checking the allowed range. A failed parse can leave a zero slot that resembles legitimate input in another domain.

Avoid hiding required work inside a condition that might be skipped. Keep source updates and actions separate from descriptive checks. The fixed-input examples calculate decisions only; printing a positive flag is not enforcement of a permission or completion of an external action.

using System;

string? name = null;
bool hasUsableName = !string.IsNullOrWhiteSpace(name) && name.Trim().Length >= 2;
Console.WriteLine($"Usable name: {hasUsableName}");

Select Run code to compile and execute this program.

Usable name: False

using System;

string text = "two";
bool parsed = int.TryParse(text, out int quantity);
bool quantityAllowed = parsed && quantity >= 1 && quantity <= 6;
Console.WriteLine($"Parsed: {parsed}");
Console.WriteLine($"Result slot: {quantity}");
Console.WriteLine($"Allowed: {quantityAllowed}");

Select Run code to compile and execute this program.

Parsed: False
Result slot: 0
Allowed: False

Unknown is a separate state when the field needs it

Ordinary bool has two values. A nullable bool? adds null, which can model a question that has not been answered. Use this only when the domain actually distinguishes unknown from an explicit false; adding a third state without a reason makes rules harder to explain.

The example compares accepted to true and false separately. When accepted is null, both comparisons are false. Therefore not explicitly accepted does not prove explicitly declined. HasValue tells you whether an answer is present.

Nullable logical operators have their own rules, and && and || do not directly combine bool? operands in the same way as ordinary bool. For this beginner decision, explicit accepted == true produces a bool with an understandable policy. Detailed three-valued logic can wait until you need it.

using System;

bool? accepted = null;
bool explicitlyAccepted = accepted == true;
bool explicitlyDeclined = accepted == false;
Console.WriteLine($"Answered: {accepted.HasValue}");
Console.WriteLine($"Accepted: {explicitlyAccepted}");
Console.WriteLine($"Declined: {explicitlyDeclined}");

Select Run code to compile and execute this program.

Answered: False
Accepted: False
Declined: False

Find a counterexample instead of trusting a happy path

A rule is easiest to trust when you can explain which input would make it fail. Start with a valid case, then close each mandatory gate independently. For alternatives, test neither route, only the first, only the second and both. A bypass often appears in a closed-gate case with one route still true.

For numeric conditions, test just below, exactly at and just above each boundary. If exactly three steps are required, completedSteps >= requiredSteps should include three. A test with ten completed steps would not reveal a mistaken strict greater-than comparison.

Name the decision and its supporting conditions clearly, and state the assumptions behind source data. The practice lab uses trusted fixed facts and nonnegative step counts. A real system must obtain and enforce its own authoritative facts rather than accepting a client-computed true flag.

Guided repair: a route must not bypass the gate

Membership should not permit a request when a workshop is closed. The broken expression says it can. Repair the grouping and add the missing positive-count requirement, then test each gate independently.

using System;

bool member = true;
bool invited = false;
bool workshopOpen = false;
int requested = 2;
int seatsAvailable = 3;
bool canRequest = member || invited && workshopOpen && requested <= seatsAvailable;
Console.WriteLine($"Can request: {canRequest}");

Select Run code to compile and execute this program.

Can request: True

Repair checkpoints

1. Keep membership or invitation as one named alternative route.
2. Require workshopOpen for both routes.
3. Require requested > 0 and requested <= seatsAvailable.
4. The reference closed workshop must produce False.
5. An open workshop with either route and an exact-stock positive request succeeds; no route, zero request or insufficient stock fails.

using System;

bool member = true;
bool invited = false;
bool workshopOpen = false;
int requested = 2;
int seatsAvailable = 3;
bool hasRoute = member || invited;
bool quantityAllowed = requested > 0 && requested <= seatsAvailable;
bool canRequest = hasRoute && workshopOpen && quantityAllowed;
Console.WriteLine($"Can request: {canRequest}");

Select Run code to compile and execute this program.

Can request: False

Independent lab: a practice-submission rule

Create a practice-submission decision. A lesson must be open, the account must be active, at least one access route must exist, and the required number of steps must be complete. Name the supporting conditions so the rule reads like its requirement.

Acceptance checklist

• Use the six fixed values in the starter without changing the policy to fit them.
• Mark stepsComplete when completedSteps >= requiredSteps.
• Mark hasAccessRoute when member or practicePass is true, including both.
• Require lessonOpen, accountActive, hasAccessRoute and stepsComplete together.
• Print Steps complete: True and Can submit: False for the reference inactive account.
• Assume nonnegative step counts and authoritative source facts; this exercise prints a decision without submitting or authorizing anything.

using System;

bool lessonOpen = true;
bool accountActive = false;
bool member = true;
bool practicePass = false;
int completedSteps = 3;
int requiredSteps = 3;

bool ready = completedSteps > requiredSteps;
bool canSubmit = member || practicePass && lessonOpen && accountActive && ready;
Console.WriteLine($"Steps complete: {ready}");
Console.WriteLine($"Can submit: {canSubmit}");

Select Run code to compile and execute this program.

Steps complete: False
Can submit: True

using System;

bool lessonOpen = true;
bool accountActive = false;
bool member = true;
bool practicePass = false;
int completedSteps = 3;
int requiredSteps = 3;

bool stepsComplete = completedSteps >= requiredSteps;
bool hasAccessRoute = member || practicePass;
bool canSubmit = lessonOpen && accountActive && hasAccessRoute && stepsComplete;
Console.WriteLine($"Steps complete: {stepsComplete}");
Console.WriteLine($"Can submit: {canSubmit}");

Select Run code to compile and execute this program.

Steps complete: True
Can submit: False

Changed-input checks

• Activate the reference account: submission becomes True.
• Close the lesson while all other gates pass: False.
• Test access routes neither, member only, pass only and both: False, True, True, True with other gates valid.
• With three required steps, test two, three and four completed steps: False, True, True with other gates valid.
• Change a source flag after calculating canSubmit and explain why the stored result must be reconsidered.

Recap: read the decision in words

Name exactly what each condition establishes. Group alternatives before combining mandatory gates, and test source changes, unknown answers and boundary values deliberately.

bool

A value that is true or false; not implicit numeric or text truthiness.

named comparison

Describe exactly what the current source values establish.

a && b

Require both facts; a false left operand skips the right.

a || b

Accept either route, including both; a true left operand skips the right.

!(a && b)

At least one requirement is missing: equivalent to !a || !b.

(a || b) && gate

Apply a mandatory gate to every alternative route.

parsed && valueAllowed

Use numeric input only after parsing succeeded.

answer == true

For bool?, require an explicit true while keeping unknown distinct from false.

Frequently asked questions

Next step and references

A Boolean decision summarizes named facts at a particular moment. Keep mandatory gates outside alternative routes, negate the intended scope, and test each requirement independently. A calculated flag describes a result; an actual system must enforce its own authoritative rules.

Next is C# If, Else If, and Else. You will use these conditions to choose which statements run, distinguish exclusive branches from independent checks, and explain each path.

Official references

Original SovranCode explanations, examples and exercises. Technical details were checked against these references.

• Microsoft Learn: bool
• Microsoft Learn: Boolean logical operators

Last updated: 26 October 2026.