AP Computer Science Principles · Unit 1
Unit 1 · Concept 5 of 5 · ~6 min read · 10–13% of AP exam
Code comments, planning notes, and clear explanations — the documentation habits that help you understand your own code later and ace the AP CSP Create Task written responses.
Program documentation is written information that explains how a program works, why decisions were made, and how someone else can understand or use the code. Good documentation includes code comments, planning notes, and testing records. On the AP CSP Create Task, strong documentation makes the exam-day written responses much easier to write.
Program documentation is written information that explains how a program works and why decisions were made. It includes code comments, planning notes, testing records, and short summaries — anything that helps another person (or future you) understand the code without having to re-read every line.
Programmers write code that other people read. Even if you're the only one who'll ever see your code, "future you" is another person. Three weeks after you finish a project, you won't remember why you wrote certain lines a certain way. Documentation is the trail of breadcrumbs that lets you find your way back.
On the AP CSP exam, documentation shows up in MCQ scenarios about code clarity, comments, and naming. On the Create Task, documentation is even more critical — the written responses on exam day ask you to describe your algorithm, your procedure, and your testing. Students who documented while building have ready answers; students who skipped documentation are reverse-engineering their own code under time pressure.
Documentation is part of the program development process, but it's not a one-time step at the end. The best programmers document as they go — adding a comment after each decision, taking notes after each testing cycle, and updating their planning notes when designs change.
Documentation also supports collaboration in computing: when a partner reviews your code, clear comments and names help them give useful feedback faster. After iterative development cycles, updated notes record what changed between versions — material you can reuse in Create Task written responses.
MCQs often show a snippet with a weak comment and ask which replacement helps most. The correct answer usually adds purpose or context, not a longer restatement of the syntax. For the Create Task, documentation is the bridge between the code you wrote months ago and the paragraphs you must produce on exam day under strict time limits.
There are 5 main types of documentation: code comments, planning notes, testing records, README-style summaries, and meaningful variable/procedure names. Each one helps a different reader in a different situation.
| Type | What it is | Best used for |
|---|---|---|
| Code comments | Notes inside the code itself, marked with // or # | Explaining why a decision was made |
| Planning notes | Written-out goals, features, and design choices | Helping you remember what you intended |
| Testing records | A table of test cases with inputs, expected results, actual results | Proving the program works and supporting Create Task Row 6 |
| README-style summary | A short overview of purpose, features, and how to use the program | Explaining the program to a new reader |
| Variable/procedure names | Clear names that explain what something is or does | Making the code self-documenting |
Strong projects use more than one type. Comments explain tricky logic; testing records support Row 6 of the Create Task rubric; a short README-style note at the top of your file reminds future-you why the program exists. Names like checkAnswer and correctCount reduce how many comments you need — but they do not replace comments on non-obvious decisions.
Planning notes can live outside the editor — a shared doc, a notebook, or the planning template on the Create Task Guide. Testing records often work best as a simple table you update after each program testing session. README-style summaries do not need fancy formatting; three sentences about purpose, audience, and how to run the program are enough for AP CSP scope.
Self-documenting code is the goal when names carry meaning: a reader sees totalCorrect and understands the variable's role without a comment. Reserve comments for decisions names cannot carry — why you chose one algorithm over another, why a boundary value matters, or why a procedure runs only after validation passes.
Good comments explain WHY a line or block of code exists. Weak comments just describe WHAT the line does literally — which the reader can already see by looking at the code. The difference is whether the comment adds information.
| Weak comment | Better comment |
|---|---|
// This adds 1 | // Increase score after a correct answer |
// Button code | // Run the answer check when the user clicks Submit |
// Loop | // Repeat through each vocabulary word in the list |
// Variable | // Track how many questions the user has answered correctly |
// Function | // Compare the user's answer to the correct one and update score |
The rule: If a comment doesn't say anything the code doesn't already say, it's clutter. Good comments add information about purpose.
Misleading comments — ones that describe the wrong behavior — are worse than no comment at all. Whenever you change code during iterative development, check whether nearby comments still match what the line actually does.
How this shows up in the Create Task
Documentation directly affects your exam-day written responses. Rows 1, 4, 5, and 6 of the rubric ask you to describe your program's purpose, your procedure, your algorithm, and your testing — all things you should have documented while building. Students who comment as they code have a much easier time writing these responses than students who try to remember everything at the end.
Documentation matters for AP CSP in three ways: it's tested in MCQs, it helps you write stronger Create Task written responses, and it makes debugging and refinement easier during development.
Look for questions that show a code snippet with weak comments and ask which improvement helps the most. Correct answers usually involve adding purpose, not just describing the action. When two answer choices both add comments, pick the one that explains why the code exists in the program, not what operator the line uses.
The written responses ask you to describe your code segments. If you documented while building, you already know what each segment does and why. If you didn't, you'll be reading your own code on exam day trying to remember. Testing records from program testing double as documentation for Row 6 — inputs, expected outputs, and what actually happened.
Comments and notes save time when you return to code after a few days. You'll find the right line faster, understand your past decisions, and avoid breaking working code. Official Big Idea 1 standards on College Board AP Central treat readable, explainable programs as part of creative development — documentation is how you prove you understand what you built.
If you collaborate with a classmate on testing, ask them to note what confused them in writing — those notes become documentation you can reference when you refine the interface or add clearer labels. Good documentation is not a separate chore; it is the written trail of the same decisions you already make while designing, testing, and iterating.
Use this checklist while building your Create Task. Tick each item when it is true for your project. Progress saves in this browser session.
0 of 8 documented
Read each code snippet with its comment and choose Strong, Weak, or Misleading. You'll get immediate feedback after each answer. Progress saves in this browser session.
After the quiz, revisit the good vs weak table above and run through the documentation checklist on your own Create Task draft.
Question 1 of 6
Review any missed ratings in the good vs weak table, then try the AP-style questions below.
| Mistake | Why it hurts | Better approach |
|---|---|---|
| Comments that just describe the line literally | They add clutter without adding information | Explain WHY the line exists, not what it does |
| No comments at all | Future-you (and graders) can't follow your decisions | Comment after every important decision |
| Misleading comments | Worse than no comments — they actively confuse | Update comments when you change the code |
| Comments that copy variable names | "this is the score variable" adds nothing | Explain the purpose of the variable, not its existence |
| Documentation only at the end | You forget the WHY by then | Document while you code |
| Cryptic variable names with no comments | The code becomes unreadable | Use descriptive names — comments are a backup, not a fix |
When you fix a bug after testing, update both the code and any comment that described the old behavior. Misleading documentation is a common trap on MCQs that ask you to pick the best improvement — the wrong answer often adds more words without adding meaning.
Students sometimes treat documentation as punishment — extra typing after the "real" work of coding. Flip that mindset: comments are how you capture decisions while they are still fresh. The ten seconds you spend writing // Reject blank answers before comparing strings can save twenty minutes on exam day when you must describe that logic in a written response.
These three questions mirror common Unit 1 MCQ patterns about weak comments, strong comments, and why documentation matters for the Create Task. Click an answer to see whether you are correct and read the explanation.
1. A student adds the comment // This is a loop to a for loop in their code. What's the problem with this comment?
Why A is wrong: Comments are encouraged when they add information — the problem here is content, not presence.
2. Which comment is the strongest for a line that increases a user's score?
Medium3. Why does program documentation matter for the AP CSP Create Task specifically?
HardAP tip: Document purpose, procedure logic, and test evidence while you build — not the night before the exam.
Tick each line when you can explain the idea without looking at the tables above. When all five are checked — including the last one — you have finished all five Unit 1 concept pages.
0 of 5 ready
Program documentation is written information that explains how a program works, why decisions were made, and how someone can understand or use the code. It includes code comments, planning notes, testing records, and short summaries. Documentation is for both future-you and any other reader who might encounter your code.
A good comment explains WHY a line exists or what purpose it serves. A weak comment just describes WHAT the line does literally, which the reader can already see. For example, // Increase score after a correct answer is better than // Add 1 because it tells you the purpose.
Documentation directly supports the Create Task written responses. Rows 1, 4, 5, and 6 of the rubric ask you to describe your program's purpose, procedure, algorithm, and testing — all things you should have documented while building. Students who comment as they code write much stronger responses than students who try to remember everything at the end.
No. Documenting every line creates clutter. Focus on documenting decisions, complex logic, and parts that aren't obvious from reading the code. A clear variable name often does the job of a comment without taking up extra space.
A README is a short overview at the start of a project that explains what the program is, what it does, and how to use it. For a Create Task, a README-style summary can be as simple as 3-4 sentences: purpose, main feature, who it's for, how to run it. This is useful for your own reference and as a starting point for the written responses.
Yes, and it's often a better choice. correctAnswerCount doesn't need a comment because the name explains itself. c definitely needs one. Self-documenting code (clear names + clear structure) reduces the need for comments — but doesn't eliminate them entirely.
This is one of the worst documentation mistakes. Misleading comments are worse than no comments because they actively confuse the reader. Whenever you change a line of code, check whether the comment still describes it correctly. If not, update both.
The multiple-choice exam will test your understanding of what good documentation looks like — usually by showing a code snippet with a weak or strong comment and asking which improvement helps the most. For the Create Task, documentation isn't graded directly, but it's the foundation for your written responses, which are graded.