Boolean operations in a programming language

Boolean operators combine or modify Boolean values (True/False) and always produce a Boolean.

AND — both must be true

A	B	A AND B
False	False	False
False	True	False
True	False	False
True	True	True

Only one row is True. Think of it as the strict operator — everything must pass.

OR — at least one must be true

A	B	A OR B
False	False	False
False	True	True
True	False	True
True	True	True

Only one row is False. Think of it as the lenient operator — one pass is enough.

⚠️ Note the last row. In everyday English "or" often means one or the other but not both ("tea or coffee?"). In programming, OR includes both — True OR True is True. The exclusive version is XOR, which you meet in 3.4.2 logic gates but not here.

NOT — reverse the value

A	NOT A
False	True
True	False

AQA tip. These truth tables reappear in 3.4.2 Boolean logic, where you must construct them for logic gates using AQA's notation (. for AND, + for OR, overbar for NOT). Learning them properly here means half of 3.4.2 is already done.

The two patterns you must know cold

Checking a value is INSIDE a range → AND

IF mark ≥ 0 AND mark ≤ 100 THEN
    OUTPUT 'Valid'
ENDIF

Both must be true. A mark of 50 satisfies both. A mark of 500 satisfies the first but fails the second, so the whole condition is False. Correct.

Checking a value is OUTSIDE a range → OR

IF mark < 0 OR mark > 100 THEN
    OUTPUT 'Invalid'
ENDIF

Either is enough. A mark of −5 satisfies the first; 500 satisfies the second; either makes the value invalid. Correct.

Why an OR range check is catastrophic — not just wrong

This is the error worth understanding properly, because examiners test whether you grasp how badly it fails:

IF mark ≥ 0 OR mark ≤ 100 THEN     # WRONG

Try to find a number this rejects:

• 500 → is it ≥ 0? Yes → accepted.
• −50 → is it ≤ 100? Yes → accepted.
• 1000000 → ≥ 0? Yes → accepted.

Every possible number satisfies at least one side. The condition is always True, so the validation does absolutely nothing. It is not a weak check — it is no check at all.

And the mirror error

IF mark < 0 AND mark > 100 THEN    # WRONG

This asks for a number that is simultaneously below 0 and above 100. No such number exists, so the condition is always False and nothing is ever flagged as invalid.

The decision rule

Ask: "must BOTH things be true at the same time?"

If the answer is…	Use	Example
Yes, both must hold	AND	"aged 18 or over and a member"
No, either is enough	OR	"pay by card or cash"
I need the opposite	NOT	"not already logged in"

AQA tip. Test every compound condition with two deliberately awkward values — one that should pass and one that should fail. If your "invalid" check never triggers, or your "valid" check never rejects, you have swapped AND and OR.

The specification requires combinations of these operators within conditions.

Precedence order

Priority	Operator
1 (highest)	NOT
2	AND
3 (lowest)	OR

So A OR B AND C means A OR (B AND C) — the AND binds tighter.

Why this matters

IF isAdmin OR isMember AND hasPaid THEN

Because AND binds first, this is isAdmin OR (isMember AND hasPaid) — an admin gets in regardless of payment. If you intended "(admin or member) and has paid", you must bracket it:

IF (isAdmin OR isMember) AND hasPaid THEN

These two conditions behave completely differently. An unpaid admin passes the first and fails the second.

The practical rule: whenever you mix AND with OR, use brackets. They cost nothing, remove ambiguity and make your intent unmistakable to an examiner.

Three-part conditions

# Valid mark that is also a pass
IF mark ≥ 0 AND mark ≤ 100 AND mark ≥ 40 THEN

# Weekend OR a bank holiday, and the shop is open
IF (isSaturday OR isSunday OR isBankHoliday) AND isOpen THEN

Using NOT

IF NOT found THEN
    OUTPUT 'Item not in list'
ENDIF

WHILE NOT finished
    …
ENDWHILE

NOT with a Boolean flag reads naturally and is preferred to found = False. Both work; NOT found is cleaner.

NOT applied to a comparison needs brackets:

IF NOT (age ≥ 18) THEN      # same as age < 18

This is legal but usually worse than just writing age < 18 directly — write the positive form when you can.

AQA tip. In an exam, over-bracketing is never penalised but under-bracketing can change the meaning entirely. If in doubt, bracket.

The specification specifically requires these operators "within conditions for iterative and selection structures" — so loops matter as much as IFs.

The early-exit search pattern

found ← False
i ← 0

WHILE i < LEN(items) AND found = False
    IF items[i] = target THEN
        found ← True
    ELSE
        i ← i + 1
    ENDIF
ENDWHILE

The compound condition does two jobs at once:

1. i < LEN(items) stops the loop running past the end of the array (which would cause an error).
2. found = False stops the loop as soon as the target is located, rather than pointlessly checking the rest.

Both must remain true for the loop to continue — which is exactly what AND gives you. This is the standard linear search from 3.1.3, and the same shape appears in binary search with WHILE low ≤ high AND found = False.

Validation loops

REPEAT
    OUTPUT 'Enter a mark between 0 and 100'
    mark ← STRING_TO_INT(USERINPUT)
UNTIL mark ≥ 0 AND mark ≤ 100

Careful with UNTIL. The loop repeats until the condition becomes true — so the condition here describes the valid state, using AND. The equivalent WHILE version needs the inverted condition:

WHILE mark < 0 OR mark > 100
    …
ENDWHILE

Notice both operators flipped and AND became OR. This is the inversion pattern in action.

Multiple exit conditions

WHILE attempts < 3 AND access = False
    …
ENDWHILE

The loop ends when either the attempts run out or access is granted — because with AND, either part becoming false ends the loop. This is the authentication pattern from 3.2.11.

AQA tip. A loop condition joined by AND ends as soon as any part becomes false. A loop condition joined by OR only ends when every part is false. Getting this the wrong way round produces loops that exit immediately or never exit at all.

Trap 1: x = 1 OR 2

IF answer = 1 OR 2 THEN        # WRONG
IF answer = 1 OR answer = 2 THEN   # correct

Why the first is wrong. OR combines two complete conditions, not a condition and a value. answer = 1 is a condition; 2 on its own is just a number, not a question about anything.

In many languages the broken version does not even error — it quietly evaluates 2 as "true" (any non-zero number counts as true), so the whole condition is always True and the check does nothing.

The rule: every side of AND/OR must be a complete condition with its own comparison.

Trap 2: chained comparisons

IF 0 ≤ mark ≤ 100 THEN         # valid maths, NOT valid in most languages
IF mark ≥ 0 AND mark ≤ 100 THEN    # correct

Mathematics allows chaining; most programming languages do not. Write each comparison out in full and join with AND.

Trap 3: NOT applied too widely

IF NOT age ≥ 18 AND hasID THEN

Because NOT has the highest precedence, this means (NOT age ≥ 18) AND hasID — probably not what was intended. If you meant "not (both of these)", bracket it explicitly:

IF NOT (age ≥ 18 AND hasID) THEN

Trap 4: double negatives

IF NOT (NOT found) THEN     # same as IF found THEN
WHILE NOT finished = False  # confusing — just write WHILE NOT finished

Double negatives are technically correct but genuinely hard to read, and hard-to-read code is where bugs hide. Write the positive form whenever you can.

A checklist for any compound condition

1. Is each side a complete condition with its own comparison?
2. Should both hold (AND) or is either enough (OR)?
3. If I mixed AND and OR, have I bracketed it?
4. Does a value that should pass actually pass?
5. Does a value that should fail actually fail?

AQA tip. Step 5 is the one students skip. A condition that accepts everything looks identical to a working one until you deliberately try to break it.