Skip to main content

AP® · Conceptual

AP® Computer Science Principles

All five College Board big ideas, the six computational thinking practices, and the Exam Reference Sheet: built for the 70 MC and the Create Performance Task.

Start Unit 1 free. Big Idea 1: Creative Development is open to everyone, no account needed. Other topics are locked.

Big Idea 1: Creative Development

THE BIG PICTURE. Big Idea 1 (10–13%) is about HOW PROGRAMS ARE MADE: the iterative, collaborative process of identifying needs, designing, developing, and testing solutions. The unit also covers program documentation, debugging, and the practical mechanics of writing readable, maintainable code. CSP emphasizes the SOCIAL and ITERATIVE nature of programming, in contrast to the technical depth of CS A.

COLLABORATION

Computing is rarely a solo activity. Collaboration involves:

  • Combining DIFFERENT PERSPECTIVES to develop better solutions.
  • Sharing knowledge, ideas, and feedback.
  • Pair programming, code reviews, version control.

Benefits of collaboration:

  • Catches bugs (more eyes).
  • Better designs from multiple viewpoints.
  • Faster development (parallel work).
  • Knowledge sharing and skill building.

Methods:

  • Pair programming: two people, one keyboard. One drives (types); the other navigates (reviews).
  • Code reviews: peer evaluation of proposed changes.
  • Version control: Git tracks changes and enables team work.
  • Communication: written and verbal explanation of intent and reasoning.

Diversity considerations: Computing solutions are better when developed by teams with diverse backgrounds (gender, race, culture, experience, expertise). Lack of diversity can lead to systems that fail certain user groups (e.g., facial recognition bias against people of color; voice assistants that don't understand certain accents).

PROGRAM DESIGN AND DEVELOPMENT

The development process is ITERATIVE (going through cycles), not linear.

Phases (general):

1. Investigating and reflecting: identify what users need and existing solutions. 2. Designing: plan the structure; outline algorithms; sketch user interface. 3. Prototyping: build a small working version to test ideas. 4. Testing: try the prototype with users; identify problems. 5. Iterating: revise based on findings; repeat.

User involvement: consult intended users at every phase. Real users find problems developers miss.

The development cycle The CED names four common phases. An iterative process loops back when feedback or testing reveals a problem; an incremental process gets one small piece working before adding the next.

Iterative vs incremental (CED 1.3). The CED names two development styles, and a question may ask you to tell them apart. An iterative process refines and revises the program based on feedback, testing, or reflection, which can mean going back to an earlier phase. An incremental process breaks the problem into smaller pieces and makes sure each piece works before adding it to the whole. Real teams usually do both. Investigation can use surveys, user testing, interviews, and direct observation; the design phase can include brainstorming, storyboarding, organizing the program into modules, diagrams of the user interface, and a testing strategy.

PRACTICE: ITERATIVE, INCREMENTAL, OR SOMETHING ELSE?

ScenarioProcessWhy
A team builds the login screen, tests it until it works, then starts the scoreboardIncrementalOne piece works before the next is added
After a user test, a team redesigns the menu they finished last weekIterativeFeedback sends them back to an earlier phase
A developer writes every feature, then tests the whole app once at the endNeither (linear)No feedback loop and no piece-by-piece checking
Students interview five librarians before sketching a book-finder appInvestigatingGathering user needs before designing

Agile vs Waterfall (not deeply tested): waterfall = linear phases; agile = short iterative cycles. CSP emphasizes agile/iterative.

Program requirements: SPECIFY WHAT the program must do BEFORE deciding HOW.

  • Functional requirements: what features.
  • Non-functional requirements: speed, security, accessibility, etc.

DOCUMENTATION AND COMMENTS

Comments are notes inside code, intended for human readers (ignored by computer). Good comments explain WHY, not WHAT.

Bad comment: x = x + 1 // increment x (obvious from code). Good comment: x = x + 1 // adjust for off-by-one because list is 0-indexed but spec is 1-indexed.

Types of documentation:

  • Inline comments.
  • Function/method comments (purpose, parameters, return value).
  • External documentation (README, user guides).
  • Code structure and naming (self-documenting code).

Benefits:

  • Future you / others can understand the code.
  • Aids debugging (clarifies intent vs implementation).
  • Speeds onboarding of new collaborators.

What the CED adds. Documentation is a written description of what a code segment, event, procedure, or program does and how it was developed. Document throughout development, not only at the end. Not every programming environment supports comments, so other methods may be needed. If you use code written by someone else, or developed with a partner, acknowledge it in the documentation with its origin or the original author's name (the Create task requires this too).

CASE STUDY: THE MARS CLIMATE ORBITER (1999)

NASA lost the Mars Climate Orbiter on September 23, 1999, as it tried to enter orbit around Mars. The investigation board found the root cause at a hand-off between teams: a ground software file that reported thruster data was delivered in English units (pound-force seconds), while the navigation software expected the specified metric units (newton-seconds). The small errors added up over the nine-month trip, and when the spacecraft reached Mars its trajectory was about 170 kilometers lower than planned.

  • Concept: collaboration and documentation. Each program did what its authors intended; the failure lived in the agreement between teams.
  • What it shows: a program's specification (its requirements) only helps if every collaborator follows it, and testing has to check how the pieces work together.
  • Exam link: questions about why communication, documentation, and testing matter in collaborative development.

DEBUGGING

A bug is an unintended behavior of a program. Debugging = process of finding and fixing bugs.

Types of errors:

  • Syntax error: code violates language grammar; won't compile/run (e.g., missing semicolon, mismatched brackets).
  • Runtime error: code crashes during execution (e.g., dividing by zero, accessing index out of bounds).
  • Logic error: code runs but produces WRONG result (the hardest to debug; the code is "wrong" not "broken").
  • Overflow error: number too big for data type.

Debugging techniques:

  • Trace the program by hand or with a debugger.
  • Print statements to display values at key points.
  • Test individual functions in isolation.
  • Compare expected vs actual output.
  • Read error messages CAREFULLY.
  • Reproduce the bug consistently before fixing.

Test cases:

  • Normal inputs: typical expected usage.
  • Boundary / edge cases: extreme values (empty, max, min, 0, 1, negative).
  • Invalid inputs: malformed or unexpected.
  • Stress tests: very large inputs.

Sorting out the four error types Ask the questions in order: does it follow the language rules, does it stop partway, is a number out of range, is the result wrong? Each answer points to the CED error type and a typical example.

CED definitions to know (1.4). A logic error makes the algorithm or program behave incorrectly or unexpectedly. A syntax error breaks the rules of the programming language. A run-time error happens during execution, and each language defines its own (on the Exam Reference Sheet, a list index less than 1 or greater than the length of the list produces an error and the program terminates). An overflow error happens when the computer tries to handle a number outside its defined range. The CED's toolkit for finding errors: test cases, hand tracing, visualizations, debuggers, and extra output statements.

WORKED EXAMPLE: A LOGIC ERROR THAT ONLY SOME TESTS CATCH

This procedure is meant to return the largest value in a list of numbers.

PROCEDURE findMax(nums)
{
    max ← 0
    FOR EACH n IN nums
    {
        IF(n > max)
        {
            max ← n
        }
    }
    RETURN(max)
}

Choose test inputs that cover different situations, then compare expected and actual results.

Test inputExpectedActualResult
[4, 9, 2] (largest in the middle)99pass
[9, 4, 2] (largest first)99pass
[2, 4, 9] (largest last)99pass
[7] (one element)77pass
[-5, -2, -9] (all negative)-20fail

Diagnosis. The procedure runs and returns a value every time, so this is not a syntax or run-time error. It is a logic error: max starts at 0, and no negative number is greater than 0, so the procedure returns a value that is not even in the list. Fix: start with max ← nums[1], the first element. The four passing tests look thorough but share a hidden assumption (positive numbers); a good test set varies the kind of input, not just its order.

One more edge case. With the fix, findMax([]) evaluates nums[1] on an empty list. The Exam Reference Sheet says an index greater than the length produces an error and the program terminates: a run-time error. The program's requirements (for example, "the list always holds at least one score") tell you whether that input needs handling.

WORKED EXAMPLE: TESTING AT AND JUST BEYOND THE EXTREMES

The CED says test inputs should include values at or just beyond the minimum and maximum. A rating app accepts whole-number ratings from 1 to 5, and a teammate wrote this check.

PROCEDURE isValidRating(r)
{
    IF((r > 1) AND (r ≤ 5))
    {
        RETURN(true)
    }
    RETURN(false)
}
InputWhy test itExpectedActual
0just below the minimumfalsefalse
1at the minimumtruefalse
3a typical valuetruetrue
5at the maximumtruetrue
6just above the maximumfalsefalse

Only the test at 1 exposes the bug; the condition should use r ≥ 1. A test set of 2, 3, and 4 would pass every case and hide the error. Also notice that RETURN ends the procedure immediately, so when the IF condition is true the second RETURN never runs.

PRACTICE: NAME THAT ERROR

SymptomError typeWhy
The program will not start; the editor flags a missing closing braceSyntaxThe language's rules are broken
A loop reads scores[i] and the program halts when i reaches LENGTH(scores) + 1Run-timeHappens during execution; the index is out of range
The average of 80, 90, and 100 prints as 270LogicRuns fine; the algorithm never divides by 3
A counter stored in 8 bits goes from 255 to 0Overflow256 is outside the range of 8 bits

CASE STUDY: THE THERAC-25 (1985 TO 1987)

The Therac-25 was a computer-controlled radiation therapy machine. Between June 1985 and January 1987, six known accidents involved massive overdoses, with resulting deaths and serious injuries, according to a widely cited investigation by Nancy Leveson and Clark Turner. Earlier models in the same family had independent hardware safety circuits; the Therac-25 relied much more on software. One bug the investigators described was a one-byte counter that went up by 1 on each pass through a setup routine. On every 256th pass it overflowed to 0, and a value of 0 caused a safety check to be skipped.

  • Concept: program errors, including overflow, and the limits of testing.
  • What it shows: a rare bug can pass ordinary testing. This one needed exact timing: the operator pressing a key at the moment the counter rolled over.
  • Lesson: safety-critical software needs testing at the extremes plus independent safeguards, not just "it worked when we tried it."

PROGRAM CONCEPTS YOU'LL ENCOUNTER

CSP uses PSEUDOCODE on the exam (the Exam Reference Sheet) so concepts apply regardless of specific language.

Variables: storage for a value with a name. Assignment: x ← 5 (CSP pseudocode notation).

Expressions: combinations of values, variables, operators yielding a value.

Operators

  • Arithmetic: +, -, *, /, MOD (modulus).
  • Relational: =, ≠, <, >, ≤, ≥.
  • Logical: NOT, AND, OR.

Control structures

  • Sequencing (statements in order).
  • Selection (IF/ELSE).
  • Iteration (REPEAT, REPEAT UNTIL, FOR EACH).

Procedures (functions/methods): reusable named code blocks. May have parameters and return values.

The Exam Reference Sheet uses BOTH a text-based pseudocode and a block-based representation; code in exam questions may appear in either form.

Inputs, outputs, and events (CED 1.2). Program inputs are data sent to a computer for processing: tactile, audio, visual, or text, from a user or from another program. An event (a key press, a mouse click, the program starting) is associated with an action and supplies input; in event-driven programming, statements run when triggered rather than in sequential order. Outputs are any data sent from a program to a device, usually based on the input or on the program's prior state.

WORKED EXAMPLE: PURPOSE, INPUT, OUTPUT

Describe this program the way the exam asks: "A step-counter app reads the phone's motion sensor, adds 1 to a counter each time a step is detected, and buzzes when the day's total reaches a goal the user typed in."

  • Purpose (the problem it solves): helping the user reach a daily activity goal.
  • Inputs: motion-sensor data (each detected step is an event) and the goal the user typed.
  • Outputs: the buzz (tactile output) and, presumably, the displayed count (visual output).
  • Function vs purpose: "adds 1 per step" describes how it functions; "helps you stay active" describes why it exists. Multiple-choice options often mix the two up.

EXAM CONNECTIONS. Big Idea 1 questions emphasize CONCEPT understanding more than coding. Common topics: identifying error types; recommending debugging strategies; explaining benefits of iterative development; identifying issues from diversity-blind design. The WRITTEN RESPONSE section about the student's Create Performance Task draws on this material: Written Response 1 asks how the program's design meets the needs of an expected user, and Written Response 2(b) covers errors and testing.

Key Terms

Collaboration

Working with others to combine perspectives and develop better solutions. Methods: pair programming, code review, version control. Diverse teams produce more inclusive solutions.

Iterative Development

Development process of repeated cycles: design, build, test, revise. Each cycle improves the program based on feedback. Contrasts with linear (waterfall) development.

Prototype

Early working version of a program used to test ideas with users and stakeholders. Not the final product; meant to be revised based on feedback.

Program Requirements

Specification of WHAT a program must do, decided BEFORE deciding HOW. Functional (features) and non-functional (speed, accessibility, security) requirements.

Comment

Note inside code intended for human readers, ignored by the computer. Best practices: explain WHY (intent), not WHAT (already visible in code).

Documentation

Written explanations of how a program works and how to use it. Includes inline comments, function comments, README files, user guides.

Bug

Unintended behavior of a program. Caused by errors in design or implementation.

Debugging

Process of finding and fixing bugs. Techniques: tracing, print statements, isolating functions, reading error messages, reproducing bugs consistently.

Syntax Error

Code violates language grammar (missing semicolon, mismatched brackets). Caught at compile/parse time; program won't run.

Runtime Error

Code crashes during execution. Examples: division by zero, accessing array out of bounds, null reference exception.

Logic Error

Code runs without crashing but produces WRONG result. The code is misguided, not broken. Hardest type to find; requires careful tracing and testing.

Overflow Error

Result of computation exceeds the maximum value the data type can represent. May silently wrap around or throw an error depending on system.

Test Case

A specific input + expected output pair used to verify correctness. Categories: normal, edge/boundary (extreme values), invalid (malformed), stress (very large).

Boundary (Edge) Case

Test input at the extremes: empty, max, min, 0, 1, negative. Common bug location. Critical for thorough testing.

Pseudocode

Language-agnostic notation for describing algorithms. CSP uses its own pseudocode on the Exam Reference Sheet. Assignment: 'x ← 5'. Both text and block versions provided.

Exam Reference Sheet

Provided on AP CSP exam. Contains text-based pseudocode and block-based programming representations. Lists procedures, control structures, list operations.

Diversity in Design

Teams of varied backgrounds produce more inclusive solutions. Examples of failure when missing: facial recognition bias, voice assistants missing accents, products designed only for one demographic.

Exam Tips

  • Iterative > linear development: cycles of design-build-test-revise based on feedback.
  • Three error types: syntax (won't compile), runtime (crashes), logic (wrong output but runs).
  • Edge cases: test extremes (empty, max, min, 0, 1, negative). Classic bug-hiding spots.
  • Good comments explain WHY, not WHAT. Code shows what; comments add intent.
  • Diversity in teams produces more inclusive products. Lack of diversity → biased systems.
  • Functional vs non-functional requirements: features vs performance/accessibility/security.
  • Exam Reference Sheet is provided: both block-based and text-based pseudocode. Exam code may appear in either form.

Now practice this topic

Test yourself on what you just read.

End of the free unit

Ready to keep going?

That was the free first unit of the AP® Computer Science Principles Course Companion. Unlock the complete guide to continue with the rest of the course.

  • All 6 topics with full study notes
  • 144 flashcards
  • 111 practice questions with explanations
  • 24 free-response problems with worked solutions
  • 123 key terms

$24.99 one-time, 12 months of access.

Taking more than one course? Student Pass: up to 3 guides, $49.99 · Platinum Unlimited: every guide, $74.99.

Already bought it? Sign in

Preparing for other exams? AP® Computer Science AAP® CybersecurityAP® Calculus AB & BC

The Prep Den AP® Computer Science Principles study guide is a complete companion for revising the course: topic-by-topic study notes, interactive flashcards, practice quizzes with worked explanations, a key-terms bank, and exam-technique tips. The first unit above is free to use; the full guide unlocks every topic.

Also searched as: AP Computer Science Principles study guide, AP CSP study guide, AP CS Principles study guide, AP Computer Science Principles quiz, AP CSP quiz, AP CS Principles quiz, AP Computer Science Principles practice quiz, AP CSP practice quiz, AP CS Principles practice quiz, AP Computer Science Principles practice questions, AP CSP practice questions, AP CS Principles practice questions, AP Computer Science Principles flashcards, AP CSP flashcards.