AP CSP Big Idea 3 Study Notes: Working with Data Using Variables, Lists, Expressions, and Text

Variables and Assignments

What a variable is (and why you need it)

A variable is a named storage location for a value that can change while a program runs. You can think of a variable as a labeled box: the label is the variable’s name, and the contents of the box is the current value.

Variables matter because nearly every interesting algorithm needs to remember information as it works. For example, if you’re computing a total cost, you need a place to store the running total; if you’re finding the largest number in a set, you need a place to store “the largest so far.” Without variables, your program can’t adapt to input, make decisions based on earlier steps, or build results over time.

In AP CSP, you’ll often see variables used for:

Storing input (a score, a username, sensor data)
Keeping track of progress (a counter, a score in a game)
Temporarily holding intermediate results (an average before rounding)

Assignment: setting or updating a variable

An assignment statement sets a variable to a value. In the AP CSP Exam Reference Sheet pseudocode, assignment is shown with a left arrow.

x ← 10
name ← "Ada"

The key idea: assignment is not a claim that two things are mathematically equal forever. It is an action that makes the variable store a value at that moment. A variable can be reassigned later.

score ← 0
score ← score + 1

That second line often confuses students at first. Read it as: “Take the current value of score, add one, and store the result back into score.” This is the foundation of counters and running totals.

Variables vs. equality (a common confusion)

In math class, you might write something like “x = x + 1” and recognize it’s impossible. In programming, you do not typically use a single equals sign for assignment in AP CSP pseudocode—assignment uses ← specifically to avoid this confusion.

In AP CSP-style pseudocode:

← means “store this value in the variable” (assignment)
= is used for comparison in expressions like conditions (checking whether two values are equal)

How assignment executes (step-by-step)

When a computer executes an assignment like:

total ← price + tax

it generally does this in order:

Evaluate the expression on the right side (price + tax) using the current values of variables.
Store the computed result into the variable on the left side (total).
Overwrite whatever used to be in total.

This “evaluate then store” order is essential when tracing code.

Common variable patterns you’ll use

1) Counter: tracks how many times something happens.

count ← 0
count ← count + 1

2) Accumulator (running total): adds up values over time.

sum ← 0
sum ← sum + newValue

3) Swap using a temporary variable: necessary when you need to exchange two values.

temp ← a
a ← b
b ← temp

A helpful memory aid: a counter counts; an accumulator accumulates.

Worked example: tracing variable updates

Suppose you have:

x ← 3
y ← 2
x ← x + y
y ← x - y
x ← x - y

If you trace it carefully:

After x ← x + y, x becomes the old x plus the old y.
Later lines use the updated values.

This is exactly the kind of reasoning you need for AP CSP questions that ask you to predict the final value of a variable.

Exam Focus

Typical question patterns:
- Trace a short pseudocode segment and report the final value of one or more variables.
- Identify what a variable represents in a real-world scenario (for example, “running total,” “highest score so far”).
- Determine which line correctly updates a variable (especially counters/accumulators).
Common mistakes:
- Treating assignment as a permanent equation instead of an update.
- Using the “old” value when a variable has already been reassigned.
- Confusing equality comparison (=) with assignment (←) when interpreting pseudocode.

Data Abstraction (Lists)

What data abstraction is

Data abstraction is representing complex information in a simplified way that makes it easier to store, process, and reason about. In AP CSP, the most common abstraction you’ll use is the list.

A list is an ordered collection of elements. Those elements can be numbers, strings, Booleans, or even other lists. Lists matter because real programs rarely work with just one piece of data—they work with collections of data: a class roster, a playlist, daily temperatures, clicks on a website, or moves in a game.

By using a list, you can write one algorithm that works for any length of data rather than rewriting code for each individual value.

How lists work: order, indexing, and access

Lists are ordered, meaning position matters. In AP CSP pseudocode, list indexing is 1-based: the first element is at index 1.

If you have:

nums ← [10, 20, 30]

Then:

nums[1] is the first element
nums[3] is the third element

This is a frequent point of confusion for students who have coded in languages like Python or JavaScript, which use 0-based indexing. On the AP exam, follow the reference sheet: indexing starts at 1.

You can also update elements by assigning to a position:

nums[2] ← 99

Now the list is [10, 99, 30].

Core list operations (AP CSP-style)

AP CSP pseudocode commonly uses operations like:

APPEND(list, value): add to the end
INSERT(list, index, value): put value at a position (shifting later elements)
REMOVE(list, index): delete value at a position (shifting later elements)
LENGTH(list): number of elements

These operations matter because many algorithms rely on changing a collection over time: adding new data, removing invalid data, or scanning through all items.

Why lists are an abstraction (not just “multiple variables”)

It’s possible to store several related values in separate variables, but it quickly becomes unmanageable:

You’d need a different variable name for each item.
Your algorithm would need separate lines for each item.
You couldn’t easily scale to more data.

A list abstracts away the number of items. Instead of “temperatureMonday, temperatureTuesday, …,” you can store all temperatures in one structure and process them with the same logic.

Worked example: computing an average using a list

Imagine scores is a list of test scores. To compute the average, you conceptually:

Start a running total at zero.
Add each score to the total.
Divide by the number of scores.

In pseudocode:

scores ← [80, 90, 70, 100]
sum ← 0
i ← 1
REPEAT LENGTH(scores) TIMES
{
  sum ← sum + scores[i]
  i ← i + 1
}
avg ← sum / LENGTH(scores)

This example shows how lists connect directly to variables and expressions:

sum and i are variables that change.
sum + scores[i] is a mathematical expression.
LENGTH(scores) is used both for repetition and the final division.

Lists of lists (a powerful extension)

A list element can itself be a list. This is useful for representing things like tables (rows and columns) or coordinates.

Example:

points ← [[1, 2], [3, 4], [5, 6]]

Here, each element is a pair. This kind of structure lets you keep related values together.

What goes wrong with lists

Students commonly run into a few predictable issues:

Off-by-one errors: using index 0 or going past LENGTH(list).
Confusing an element with the list: scores is the whole list; scores[i] is one item.
Forgetting that INSERT/REMOVE shift positions: after a removal, what used to be at index 3 might now be at index 2.

Exam Focus

Typical question patterns:
- Determine what a list contains after APPEND/INSERT/REMOVE operations.
- Trace an algorithm that uses indexing and LENGTH to process a list.
- Explain how using a list is an example of data abstraction (why it improves manageability or scalability).
Common mistakes:
- Using 0-based indexing instead of the AP CSP 1-based indexing.
- Accessing list[LENGTH(list) + 1] (out of bounds) when looping.
- Not accounting for index shifts after INSERT or REMOVE.

Mathematical Expressions

What an expression is

An expression is a combination of values, variables, and operators that can be evaluated to produce a single value. A mathematical expression specifically evaluates to a number.

Expressions matter because algorithms are built from transformations: you take input data, compute intermediate results, and produce outputs. Those computations are expressed using mathematical expressions.

For example, computing a discounted price, converting units, scoring a game, or calculating an average all rely on numerical expressions.

Operators you’ll see in AP CSP-style problems

AP CSP pseudocode commonly uses arithmetic operators such as:

Addition, subtraction, multiplication, division
MOD (remainder)

The remainder operator is especially useful for:

Checking whether a number is even or odd
Wrapping around cycles (like days of the week)
Extracting digits

How expressions are evaluated (order matters)

When multiple operations appear, evaluation follows an order of operations (parentheses first, then multiplication/division, then addition/subtraction). If you don’t use parentheses intentionally, you might compute a different result than you mean.

In code, parentheses are your way of telling the computer “do this part first.” This matters a lot in AP CSP questions where you must predict what value is stored.

Integer vs. non-integer results (be careful with division)

Division often produces a non-integer (a decimal) result. Some programming languages treat division differently depending on whether values are integers, but AP CSP pseudocode questions typically focus on your ability to reason about the intended computation rather than language-specific quirks.

To avoid mistakes on exam-style questions:

Look at the context (are you computing an average that should allow decimals?)
Notice whether the algorithm later rounds or converts the result

Worked example: percent discount

A common real-world computation is applying a percent discount.

If price is the original price and rate is the discount rate written as a decimal (for example, five percent as 0.05), then the discounted price is:

final = price - price \cdot rate

In pseudocode:

price ← 50
rate ← 0.20
final ← price - price * rate

A typical mistake is subtracting the rate directly from the price (mixing units). The rate is not dollars; it’s a proportion.

Worked example: using MOD to test even/odd

The remainder when dividing by two tells you whether a whole number is even.

n ← 17
IF (n MOD 2 = 0)
{
  result ← "even"
}
ELSE
{
  result ← "odd"
}

Conceptually, n MOD 2 is the leftover after dividing by two. If there’s no leftover, the number is even.

Random numbers as expressions (when included)

AP CSP pseudocode often includes a random-value operator in questions. When you see something like a random integer in a range, treat it as an expression that can evaluate to different values on different runs.

This matters because questions may ask:

“Which values are possible outputs?”
“How many possible values could this expression produce?”

What goes wrong with mathematical expressions

Common pitfalls include:

Forgetting parentheses and accidentally computing in a different order.
Mixing units (subtracting a percent from a dollar amount, adding minutes to hours without converting).
Assuming an expression ‘updates itself’: an expression is evaluated once; a variable only changes if you assign the result back into it.

Exam Focus

Typical question patterns:
- Predict the value stored in a variable after evaluating an arithmetic expression.
- Choose which expression correctly represents a word problem (discounts, averages, taxes, unit conversions).
- Reason about possible outputs when an expression involves randomness or MOD.
Common mistakes:
- Misreading the order of operations when parentheses are absent.
- Treating MOD as “division” instead of “remainder,” leading to wrong conclusions.
- Forgetting that variables used in an expression may have been updated earlier.

Strings

What a string is

A string is a sequence of characters used to represent text, such as names, messages, search queries, or formatted data like dates. Strings matter because many real applications are built around text: user interfaces, chat messages, file contents, URLs, and data labels.

It’s useful to explicitly separate strings from numbers:

A number is meant for arithmetic.
A string is meant for text operations.

Even if a string looks numeric (for example, a phone number), you often treat it as text because you’re not going to add or multiply it.

How strings behave in programs

Strings can be:

Stored in variables
Compared
Combined
Extracted into parts

In AP CSP contexts, you’ll most often see strings used in input/output and simple text processing.

Concatenation: building bigger strings from smaller ones

Concatenation means joining strings together. Many languages (and AP CSP-style pseudocode in many problems) use the plus operator for string concatenation.

first ← "Grace"
last ← "Hopper"
full ← first + " " + last

This is conceptually different from addition with numbers. If you accidentally store numeric data as strings, you might concatenate when you meant to add.

A common misconception looks like this:

If a is the string "2" and b is the string "3", then a + b becomes "23", not a numeric sum.

So you should always keep track of what type of data you’re working with: text or numeric.

Substrings: taking part of a string

A substring is a portion of a string. Substrings matter for tasks like:

Extracting an area code from a phone number
Checking prefixes/suffixes (like file extensions)
Parsing formatted text (like dates)

AP CSP pseudocode includes a substring operation. Even if you don’t memorize the exact function signature, the key idea is consistent: you specify where to start and how much text to take.

Conceptually:

Start at a position in the string
Take a certain number of characters
Get back a new string

Students often make off-by-one mistakes here as well—especially because indexing conventions vary across languages. On the exam, follow whatever indexing rule the question’s pseudocode implies and be consistent.

Comparing strings (and why it’s tricky)

You can compare strings for equality—checking whether two strings contain exactly the same characters in the same order.

password ← "opensesame"
IF (input = password)
{
  access ← "granted"
}

String comparisons matter in authentication, searching, filtering, and validating input.

Common issues:

Case sensitivity: "Hello" and "hello" are not the same.
Extra whitespace: leading/trailing spaces change the string.
Expecting partial matches: equality checks for exact match, not “contains.”

Strings and lists: closely related ideas

A useful way to think about strings is that they’re like lists of characters, but with specialized text operations. This connection helps you reason about operations like length and substring.

Also, many real tasks combine strings with lists:

A list of usernames
A list of messages
Splitting a sentence into a list of words (conceptually)

Even when the exact “split” operation isn’t provided, you can understand the goal: convert one big string into many smaller pieces you can process with list logic.

Worked example: creating a readable message

Suppose you want to display a message using numeric data.

name ← "Jordan"
points ← 12
message ← name + " scored " + points + " points"

This raises an important concept: some languages require converting numbers to strings before concatenation. AP CSP questions may gloss over conversion details, but when you see this pattern, the intended idea is “format text using values.” If a question focuses on a type error, the key is noticing that points is numeric while the surrounding pieces are strings.

What goes wrong with strings

Typical problems include:

Type confusion: treating numeric strings as numbers (or vice versa).
Indexing mistakes in substring operations.
Assuming strings are mutable: in many languages, you can’t directly change one character inside a string; you build a new string instead. (On AP CSP, focus on the idea that string operations produce new strings unless reassigned.)

Exam Focus

Typical question patterns:
- Predict the output of concatenation and substring operations.
- Determine whether a conditional involving string equality evaluates to true.
- Identify type-related issues when combining strings and numbers.
Common mistakes:
- Expecting concatenation to perform arithmetic (for example, joining digits instead of adding values).
- Ignoring case sensitivity or whitespace in equality checks.
- Off-by-one errors when extracting substrings (starting position and length confusion).