In AP Computer Science Principles, program documentation is a written description of the function of a code segment, event, procedure, or program and how it was developed (EK CRD-2.G.1). It includes comments, which are written for people and never affect how the program runs.
Program documentation is any written explanation of what your code does and how it got built. The CED definition (EK CRD-2.G.1) is broader than just user manuals. It covers descriptions of a single code segment, an event, a procedure, or an entire program, plus the story of how it was developed.
The most common form you'll see is comments, text written directly into the program for humans to read. Comments do not change how the program runs (EK CRD-2.G.2). But documentation isn't a one-time chore you do at the end. The CED says programmers should document throughout development (EK CRD-2.G.3), because good documentation helps you build and maintain correct programs whether you're coding alone or with a team (EK CRD-2.G.4). One more job documentation does: it's where you acknowledge code you borrowed. If you use a code segment written by someone else, the acknowledgment goes in your documentation and should include the origin or the original author's name (EK CRD-2.H.2).
Program documentation lives in Topic 1.3 (Program Design and Development) in Unit 1: Creative Development, directly supporting learning objective 1.3.C: describe the purpose of a code segment or program by writing documentation. It also powers 1.3.D, acknowledging code from other sources, since that acknowledgment belongs in the documentation itself. Think of documentation as the glue of the whole development process. When development is iterative, you revisit earlier phases based on testing and feedback (EK CRD-2.E.3), and documentation is what lets you (and your collaborators) remember why the code looks the way it does. On the AP exam, this shows up in multiple-choice questions about collaboration and code reuse, and the same skill underpins explaining your own code on the Create performance task.
Keep studying AP Computer Science Principles Unit 1
Comments (Unit 1)
Comments are the in-code form of program documentation. Every comment is documentation, but not all documentation is a comment, since some environments don't support comments and you document outside the code instead. Either way, comments never affect how the program runs.
Iterative Development Process (Unit 1)
Iteration means revising your program based on testing and feedback, sometimes circling back to earlier phases. Documentation written throughout development (EK CRD-2.G.3) is your record of those revisions, so future-you doesn't have to reverse-engineer past-you's decisions.
Program Requirements (Unit 1)
Requirements describe how a program should function before you build it. Documentation describes how it actually functions after you build it. Together they bookend the design process, and comparing them is how you check that the program does what it was supposed to do.
Troubleshooting (Unit 1)
When something breaks, documentation tells you what each piece of code was supposed to do, which makes it way faster to spot where reality diverged from the plan. This is exactly why the CED says documentation helps maintain correct programs (EK CRD-2.G.4).
Documentation shows up on the multiple-choice section as scenario questions. Typical stems ask which item would be LEAST useful to include in documentation for a collaborative project, which form of documentation is LEAST effective for explaining a complex algorithm to another programmer, or which scenario shows the MOST effective use of documentation. You'll also see it tangled with code reuse, like a question asking which action could violate a Creative Commons license, where the right move involves proper acknowledgment in your documentation (EK CRD-2.H.2). The skill also matters beyond MCQs. On the Create performance task, you have to explain what your code does and credit any code segments developed collaboratively or taken from another source, which is documentation in action. No released FRQ uses the phrase verbatim, but the underlying skill (clearly describing the purpose of a code segment) is exactly what the written responses demand.
Comments are one specific type of program documentation, not a synonym for it. Comments live inside the program file and are written for people to read without affecting how the code runs. Program documentation is the bigger category, covering comments plus external write-ups, design descriptions, and acknowledgments of borrowed code. The CED even notes that not all programming environments support comments, so documentation sometimes has to live entirely outside the code.
Program documentation is a written description of the function of a code segment, event, procedure, or program and how it was developed (EK CRD-2.G.1).
Comments are documentation written into the program for people to read, and they never affect how the program runs (EK CRD-2.G.2).
You should document throughout development, not just at the end, because documentation supports the refinement and revision that iterative development requires (EK CRD-2.G.3).
Documentation helps you develop and maintain correct programs whether you're working solo or collaboratively (EK CRD-2.G.4).
Acknowledgment of code written by someone else belongs in your program documentation and must include the origin or the original author's name (EK CRD-2.H.2).
Some programming environments don't support comments, so documentation can exist outside the code itself (EK CRD-2.G.5).
It's a written description of the function of a code segment, event, procedure, or program and how it was developed (EK CRD-2.G.1). It includes comments inside the code as well as external explanations, and it supports learning objective 1.3.C in Unit 1.
No. Comments are documentation written for people to read, and the computer skips over them entirely (EK CRD-2.G.2). A program with zero comments and a program with a hundred comments run exactly the same way.
Comments are just one form of documentation, the kind written directly into the program. Documentation is the broader category, which matters because some programming environments don't support comments at all (EK CRD-2.G.5), so documentation has to live elsewhere.
During. The CED is explicit that programmers should document a program throughout its development (EK CRD-2.G.3), because iterative development means revisiting and revising code, and documentation keeps track of why changes were made.
In your program documentation, and the acknowledgment should include the origin or the original author's name (EK CRD-2.H.2). This matters on the Create performance task and in MCQs about Creative Commons licenses and code reuse.