Control Structures in AP CSP: Making Algorithms Decide and Repeat

Boolean Expressions

A Boolean expression is an expression that evaluates to exactly one of two values: true or false. You can think of it as a yes-or-no question your program can answer, such as “Is the password correct?” or “Has the player run out of lives?” Control structures (like IF statements and loops) rely on Boolean expressions to decide what to do next.

What Boolean expressions are made of

A Boolean expression is usually built from:

1. Relational (comparison) operators that compare two values
   • Examples: equal, not equal, less than, greater than
2. Logical operators that combine or modify Boolean values
   • Examples: AND, OR, NOT

In AP CSP pseudocode (the style used on the exam reference sheet), the common operators look like this:

Why Boolean expressions matter

Boolean expressions are the “decision language” of algorithms. Without them, your code would run straight from top to bottom the same way every time. With them, you can:

• Select between different actions (conditionals)
• Repeat actions until something becomes true/false (loops)
• Filter or search data (only keep items that match a condition)
• Validate input (keep asking until input is acceptable)

In other words, Boolean expressions are what let programs respond to data, users, sensors, and changing conditions.

How Boolean logic works (truth values and logic operators)

Logical operators combine Boolean values in predictable ways.

AND

A AND B is true only when both A and B are true.

Real-world analogy: “You can go outside if you finished homework and it’s not raining.” Both conditions must be satisfied.

OR

A OR B is true when at least one of A or B is true.

Important nuance: OR is inclusive here (true if either or both are true), not “exactly one.” If a question wants “exactly one,” you must build that logic explicitly.

NOT

NOT A flips the truth value.

NOT is especially useful for writing “do something unless…” conditions, but it can also make expressions harder to read if overused.

Building correct Boolean expressions

To build good Boolean expressions, you need to be precise about:

1. What you’re testing (a variable? a list length? a user choice?)
2. What counts as success (exactly equal? at least? within a range?)
3. How multiple conditions combine (AND vs OR)

Example 1: Checking a range

Suppose a discount applies only if age is between 13 and 18 inclusive.

• Correct logic: age ≥ 13 AND age ≤ 18
• Common wrong logic: age ≥ 13 OR age ≤ 18 (this is almost always true, because most ages satisfy at least one of those inequalities)

Example 2: Exactly one condition is true

If you need “exactly one of these is true” (for example, a user chose either delivery or pickup, but not both), you can express it by combining AND/OR/NOT:

• “delivery or pickup, but not both”:
  • (delivery OR pickup) AND NOT (delivery AND pickup)

Even if you’re not asked to write that exact structure, understanding it helps you reason about tricky multiple-choice options.

What goes wrong (common Boolean pitfalls)

Boolean logic is simple in concept, but small wording mistakes change meaning a lot.

• Mixing up AND and OR: “must satisfy both” vs “at least one.”
• Forgetting to compare both sides: a common beginner error in many programming languages is writing something like age ≥ 13 AND ≤ 18. AP pseudocode expects complete comparisons.
• Negating incorrectly: NOT (A AND B) is not the same as (NOT A) AND (NOT B). If you negate a grouped condition, the logic changes.
• Overcomplicating: sometimes the simplest expression is the clearest. If you can avoid double negatives, do.

Boolean expressions in action (worked traces)

Below are short AP-style pseudocode examples and how to reason through them.

Worked example 1: Combining conditions

hasTicket ← true
isVIP ← false

result ← hasTicket AND isVIP

• hasTicket AND isVIP means both must be true.
• Here it becomes true AND false, which is false.

Worked example 2: Using NOT

isBanned ← false
canJoin ← NOT isBanned

• NOT false becomes true, so canJoin is true.

Exam Focus

• Typical question patterns
  • Evaluate or simplify a Boolean expression (often with AND/OR/NOT) and choose the final true/false result.
  • Choose which Boolean expression correctly matches an English description (range checks and multi-condition rules are common).
  • Trace a short segment of pseudocode where a Boolean expression determines which branch runs.
• Common mistakes
  • Using OR when the condition requires “both,” especially for ranges.
  • Negating without parentheses (changing what NOT applies to).
  • Misreading “inclusive” vs “exclusive” conditions (≤/≥ vs </>).

Conditionals

A conditional is a control structure that chooses between different actions based on a Boolean expression. In AP CSP, the core idea is selection: your program selects which block of code to execute.

Why conditionals matter

Conditionals are how algorithms handle real-world variation:

• If the login is correct, allow access; otherwise deny.
• If a sensor reads too hot, turn on a fan.
• If the user picks “A,” do one thing; if they pick “B,” do another.

Without conditionals, a program can’t respond differently to different inputs, which would make most apps, games, and systems useless.

How conditionals work (control flow)

Conditionals typically follow this pattern:

1. Evaluate a Boolean expression.
2. If it is true, execute the “then” block.
3. Otherwise, execute the “else” block (if an ELSE exists).
4. Continue to the next statement after the conditional.

In AP-style pseudocode you’ll see structures like:

IF (condition)
{
  statements
}
ELSE
{
  statements
}

A key point: the condition is checked once at the moment execution reaches the IF.

IF vs IF-ELSE

An IF alone handles a situation where you only need an action when something is true.

• Example idea: “If the cart is empty, show a warning.”

An IF-ELSE handles two mutually exclusive paths.

• Example idea: “If the password is correct, log in; else show an error.”

If you leave out the ELSE, nothing happens when the condition is false—sometimes that’s correct, but sometimes it creates missing behavior.

Writing good conditional logic

The most reliable way to write a conditional is to be explicit about the rule:

• Identify the exact condition that should trigger the action.
• Put that condition in the IF.
• Put the alternative in ELSE (if there is a clear alternative action).

This helps avoid “accidental truthiness” (assuming something is true just because it’s non-empty) and prevents gaps where neither path does what you intend.

Conditionals in action (examples with reasoning)

Example 1: Access control

isLoggedIn ← true

IF (isLoggedIn)
{
  display("Welcome!")
}
ELSE
{
  display("Please log in.")
}

Reasoning:

• isLoggedIn is true, so the first block runs.
• The program displays “Welcome!” and skips the ELSE block.

Example 2: Using a compound condition

Suppose a user can post a comment only if they are not banned and the comment is not empty.

isBanned ← false
comment ← "Hi"

IF (NOT isBanned AND comment ≠ "")
{
  post(comment)
}
ELSE
{
  display("Cannot post.")
}

Reasoning:

• NOT isBanned becomes true.
• comment ≠ "" is true because comment is not empty.
• true AND true is true, so the post happens.

Common conditional misconceptions (what goes wrong)

• Using two separate IF statements when you need IF-ELSE: Two IFs can both run if both conditions are true. IF-ELSE guarantees only one branch runs.
• Overlapping conditions: If two different conditions can both be true, you must decide whether that overlap is intended.
• Forgetting that order matters: In chains (discussed more in nested conditionals), earlier tests can prevent later ones from ever running.

Exam Focus

• Typical question patterns
  • Trace code with an IF or IF-ELSE and determine what is displayed/returned.
  • Match a real-world rule (like “free shipping if total ≥ 50”) to the correct conditional.
  • Determine which inputs cause each branch to execute.
• Common mistakes
  • Writing logic that allows both branches when the situation is meant to be mutually exclusive.
  • Confusing assignment with equality in contexts where both symbols appear (on the exam, equality comparisons use = inside conditions).
  • Missing boundary cases (using > instead of ≥, causing edge inputs to go to the wrong branch).

Nested Conditionals

A nested conditional is a conditional inside another conditional. Nesting lets you express multi-step decision-making: you first choose a broad category, then refine the decision inside that category.

Why nesting matters

Many real rules have layers:

• If the user is logged in, then check whether they are an admin.
• If a package is international, then check which region for shipping cost.
• If a student passed, then decide whether it was a pass or an honors pass.

You could sometimes handle these with one big Boolean expression, but nesting often makes the logic clearer and reduces repetition.

How nested conditionals work (step-by-step)

When a conditional is nested, execution works like this:

1. Evaluate the outer IF condition.
2. Enter either its true block or its else block.
3. Inside the chosen block, you may encounter another IF.
4. Only the nested IFs in the executed branch are evaluated.

This is important: nesting is not “checking everything.” It’s “checking what’s relevant after earlier decisions.”

Indentation and structure (avoiding confusion)

Nesting relies heavily on structure. Good indentation is not just style—it’s how humans correctly see which ELSE matches which IF.

A frequent source of bugs is the “dangling else” problem in some languages (an ELSE attaches to the nearest unmatched IF). AP pseudocode uses explicit blocks with braces, which helps, but you still need to read carefully.

Patterns: multi-way decisions

A common pattern is an “else-if chain,” which AP-style pseudocode often represents as nested IFs:

• Check condition A
  • if true, do A’s action
  • else check condition B
  • if true, do B’s action
  • else do default action

This ensures that at most one category is chosen.

Nested conditionals in action (worked examples)

Example 1: Role-based permissions

Rule:

• If the user is not logged in, show “Please log in.”
• If logged in and admin, show “Admin panel.”
• If logged in and not admin, show “User home.”

isLoggedIn ← true
isAdmin ← false

IF (NOT isLoggedIn)
{
  display("Please log in")
}
ELSE
{
  IF (isAdmin)
  {
    display("Admin panel")
  }
  ELSE
  {
    display("User home")
  }
}

Reasoning:

• Outer IF checks NOT isLoggedIn.
• Since isLoggedIn is true, NOT isLoggedIn is false, so the program goes to the outer ELSE.
• Inside the ELSE, it checks isAdmin, which is false.
• So it displays “User home.”

Notice how the program never even considers admin status unless the user is logged in. That’s the point of the nesting.

Example 2: Grading with ordered conditions

Rule:

• If score is at least 90: A
• Else if at least 80: B
• Else if at least 70: C
• Else: D

score ← 85

IF (score ≥ 90)
{
  grade ← "A"
}
ELSE
{
  IF (score ≥ 80)
  {
    grade ← "B"
  }
  ELSE
  {
    IF (score ≥ 70)
    {
      grade ← "C"
    }
    ELSE
    {
      grade ← "D"
    }
  }
}

Reasoning (trace):

• score is 85
• score ≥ 90 is false → go to ELSE
• score ≥ 80 is true → grade becomes “B”
• The later tests are skipped because they’re inside the ELSE of the score ≥ 80 check.

A subtle but crucial idea here is ordering: you must test the highest thresholds first. If you reversed them and tested score ≥ 70 first, then a score of 95 would incorrectly get “C” because the first true condition would “catch” it.

What goes wrong in nested conditionals

• Wrong order of conditions: More general conditions placed before more specific ones can prevent the specific ones from ever running.
• Unintended overlap: If conditions overlap (for example, x ≥ 0 and x ≥ 10), you need the right structure so the intended case wins.
• Deep nesting that hides logic: If the code becomes hard to read, it’s easy to make a logical mistake. Sometimes a combined Boolean expression or a clearer else-if chain is better.

Exam Focus

• Typical question patterns
  • Trace a nested conditional and determine which message/value results for given inputs.
  • Identify which inputs lead to each branch (often by reasoning about the order of comparisons).
  • Choose a corrected version of a nested conditional that fixes logic gaps or overlaps.
• Common mistakes
  • Putting conditions in the wrong order (checking a broad condition before a stricter one).
  • Assuming all nested conditions are evaluated (only the executed path is evaluated).
  • Mis-associating an ELSE with the wrong IF when reading quickly—use the block structure carefully.

Iteration (Loops)

Iteration means repeating a set of instructions multiple times. A loop is the control structure that makes iteration happen. In AP CSP, loops are central because many problems involve doing the same operation for:

• a fixed number of times (repeat 10 times)
• every item in a list (for each name)
• until a condition becomes true (keep asking until valid)

Why loops matter

Loops let algorithms scale. Without loops, you’d have to copy-paste the same code again and again, which is error-prone and doesn’t work when the amount of data changes.

Loops also connect directly to big algorithmic ideas:

• Efficiency: looping through a list of 1,000 items is different from looping through 1,000,000.
• Correctness: a loop must stop at the right time and update the right variables.
• Data processing: counting, summing, searching, filtering, and finding maximum/minimum often depend on loops.

Types of loops you’ll see in AP CSP

AP CSP pseudocode commonly uses three iteration patterns.

1) REPEAT n TIMES (count-controlled iteration)

This loop runs a specific number of times.

REPEAT 5 TIMES
{
  display("Hello")
}

This is ideal when you know in advance how many repetitions you need.

2) REPEAT UNTIL (condition-controlled iteration)

This loop repeats while the condition is false and stops when it becomes true.

REPEAT UNTIL (guess = secret)
{
  guess ← input("Enter guess")
}

A key detail: the loop stops when the condition becomes true. Students often confuse this with “repeat while,” which is the opposite phrasing.

3) FOR EACH item IN list (list traversal)

This loop processes each element in a list.

FOR EACH name IN names
{
  display(name)
}

This is the go-to pattern for working through an entire list without manually managing an index.

How loops work (the loop cycle)

Even though loop syntax differs, the execution model is similar:

1. The loop determines whether it should run (based on count or a condition).
2. If it should run, it executes the loop body.
3. Something changes—either a counter advances, the next list item is chosen, or variables are updated.
4. The loop checks again.
5. Eventually, the loop stops and execution continues after the loop.

That “something changes” step is crucial. Many loop bugs happen because the variables that affect the stopping condition never change, so the loop never ends.

Loop patterns you should recognize

These are common algorithmic tasks built from loops.

Pattern A: Accumulation (sum, count, build a result)

You maintain a running total or count.

• Sum of a list
• Count items that meet a condition

Pattern B: Searching (find whether something exists)

You check each item until you find a match.

• Find if a name is in a list
• Find the first score above a threshold

Pattern C: Input validation (repeat until valid)

You keep asking until the input meets requirements.

Loops in action (examples with reasoning)

Example 1: Count how many items meet a condition (FOR EACH)

Goal: Count how many scores are at least 70.

scores ← [65, 70, 82, 69, 90]
count ← 0

FOR EACH s IN scores
{
  IF (s ≥ 70)
  {
    count ← count + 1
  }
}

display(count)

Reasoning:

• Start count = 0
• 65 is not ≥ 70 → count stays 0
• 70 is ≥ 70 → count becomes 1
• 82 is ≥ 70 → count becomes 2
• 69 is not ≥ 70 → stays 2
• 90 is ≥ 70 → becomes 3
• Output is 3

Notice how the loop and conditional work together: the loop visits each element, and the conditional decides whether to count it.

Example 2: Repeat until valid input (REPEAT UNTIL)

Goal: Keep asking until the user enters a non-empty name.

name ← ""

REPEAT UNTIL (name ≠ "")
{
  name ← input("Enter your name")
}

display("Hello, " + name)

Reasoning:

• The condition is name ≠ "".
• If the user enters an empty string again, the condition remains false, so the loop repeats.
• When the user finally enters something non-empty, the condition becomes true and the loop stops.

A common mistake is to read this as “repeat while name is not empty,” which would do the opposite of what you want.

Example 3: Fixed repetition with a changing variable (REPEAT n TIMES)

Goal: Simulate adding 2 points per level over 4 levels.

points ← 0

REPEAT 4 TIMES
{
  points ← points + 2
}

display(points)

Reasoning:

• Each repetition adds 2
• After 4 repetitions, points is 8

What goes wrong in loops (and how to prevent it)

Loop errors are extremely common because loops involve state changing over time.

• Infinite loops: The condition never becomes true (for REPEAT UNTIL), often because you forgot to update a variable inside the loop.
• Off-by-one errors: Doing something one too many or one too few times. This shows up when you misunderstand whether a loop includes an endpoint or when you misinterpret the stopping condition.
• Wrong stopping condition: For REPEAT UNTIL, remember it stops when the condition is true. If you choose the opposite condition, the loop will stop immediately or never stop.
• Modifying the list while traversing: In many languages, changing a list as you iterate can cause elements to be skipped or processed twice. AP exam questions may test your reasoning about list processing outcomes, so be cautious when you see list modifications inside loops.

A practical debugging tool is a trace table: write down key variable values at the start/end of each iteration to see whether they change as expected.

Exam Focus

• Typical question patterns
  • Trace how many times a loop runs and what value(s) variables have afterward.
  • Compare two loop versions (for example, a fixed-count loop vs a REPEAT UNTIL loop) and decide if they are equivalent.
  • Determine the effect of a loop that processes a list, including conditionals inside the loop body.
• Common mistakes
  • Misinterpreting REPEAT UNTIL as “repeat while,” leading to reversed logic.
  • Forgetting that the loop must change something related to its stopping condition (risking an infinite loop).
  • Off-by-one reasoning when asked “how many times does this execute?”—trace iterations carefully rather than guessing.