In AP Computer Science Principles, comments are a form of program documentation written directly into the code to be read by people; they explain what the code does and do not affect how the program runs (EK CRD-2.G.2).
Comments are notes a programmer writes inside the source code itself. The computer skips right over them when the program runs. They exist purely for humans, whether that's future-you trying to remember why you wrote a weird line of code, or a teammate trying to understand your procedure without reading every statement.
The CED is specific about where comments fit. They are one form of program documentation, which is the broader category of written descriptions of what a code segment, event, procedure, or program does and how it was developed (EK CRD-2.G.1). Comments are the version of documentation that lives inside the program (EK CRD-2.G.2). One catch worth knowing for the exam: not all programming environments support comments, so sometimes documentation has to live outside the code entirely (EK CRD-2.G.5). Comments are also a standard place to acknowledge code you borrowed from another source, including the origin or original author's name (EK CRD-2.H.2).
Comments live in Topic 1.3 (Program Design and Development) in Unit 1: Creative Development. They directly support learning objective AP Comp Sci P 1.3.C (describe the purpose of a code segment or program by writing documentation) and connect to AP Comp Sci P 1.3.D (acknowledge code segments used from other sources). The big idea here is maintainability and collaboration. The CED says documentation should happen throughout development, not at the end (EK CRD-2.G.3), and that it helps you develop and maintain correct programs whether you're working alone or on a team (EK CRD-2.G.4). On the exam, comments show up as the answer to questions about keeping code understandable, crediting other people's work, and collaborating without chaos.
Keep studying AP Computer Science Principles Unit 1
Program Documentation (Unit 1)
This is the parent concept. Documentation is any written description of what code does and how it was developed; comments are the specific kind that lives inside the program. Every comment is documentation, but not all documentation is a comment.
Iterative Development Process (Unit 1)
Because iterative development means constantly revising and revisiting earlier phases (EK CRD-2.E.3), comments written along the way are what keep you from forgetting why version 3 of your procedure works differently from version 1.
Pseudocode (Unit 1)
Both are human-readable, but pseudocode is a planning tool you write before or instead of real code, while comments are notes attached to actual running code. Pseudocode helps you design; comments help you (and others) understand what you built.
Debugging (Unit 1)
Well-commented code is dramatically easier to debug, because the comment tells you what a segment is supposed to do, so you can spot where the actual behavior drifts from the intent.
Comments appear in multiple-choice questions, usually in two flavors. The first asks about maintainability and best practices, like a question describing a programmer building a complex application and asking which development practice best supports maintainability (documenting throughout development is the move). The second flavor is attribution. A common stem describes a student who incorporates an algorithm from another source, or a team where each member writes different modules, and asks how to handle credit. The answer ties back to acknowledging the code in program documentation, including the origin or original author's name. You should be able to state what comments are, recognize that they don't affect program execution, and identify them as the in-code home for both explanations and acknowledgments.
These overlap but aren't identical. Program documentation is the whole category of written descriptions of a program's function and development; it can be a separate document, a README, or notes outside the code. Comments are the subset of documentation written into the program itself. The CED even flags that some programming environments don't support comments at all, which is exactly why documentation is the broader term. If an exam question mentions an environment without comment support, documentation still has to happen somewhere else.
Comments are written into the program for people to read and have zero effect on how the program runs (EK CRD-2.G.2).
Comments are one form of program documentation, which also includes written descriptions outside the code (EK CRD-2.G.1).
You should document a program throughout its development, not just at the end (EK CRD-2.G.3).
Documentation, including comments, helps you develop and maintain correct programs whether you work solo or on a team (EK CRD-2.G.4).
Comments are a standard place to acknowledge code from another source, and the acknowledgment should include the origin or original author's name (EK CRD-2.H.2).
Not all programming environments support comments, so documentation sometimes has to live outside the code (EK CRD-2.G.5).
Comments are annotations written inside source code for people to read. The CED defines them as a form of program documentation written into the program that does not affect how the program runs (EK CRD-2.G.2).
No. The computer ignores comments completely when executing the program. This is a frequent MCQ trap, so remember that adding, changing, or deleting comments never changes a program's output.
Comments are one type of program documentation, specifically the kind written inside the code itself. Documentation is the broader category and can also exist outside the program, which matters because some programming environments don't support comments at all (EK CRD-2.G.5).
Acknowledge it in your program documentation, often as a comment, and include the origin or the original author's name (EK CRD-2.H.2). This applies to code from the internet, a textbook, or a teammate.
No. Pseudocode is an informal, human-readable plan for an algorithm written before or instead of real code, while comments are notes attached to actual code in a program. Pseudocode is for designing; comments are for explaining what's already written.