In AP Computer Science Principles, parameters are the input variables of a procedure (EK AAP-3.A.3). They sit in the procedure definition as placeholders, and arguments fill in their actual values each time the procedure is called.
Parameters are the input variables listed in a procedure's definition. In the AP pseudocode on your exam reference sheet, they're the names inside the parentheses: PROCEDURE procName(parameter1, parameter2, ...). Think of a parameter as an empty labeled slot. The procedure's code uses that label, and the slot gets filled with a real value every time someone calls the procedure.
The value that fills the slot is called an argument. The CED is precise about this in EK AAP-3.A.3: parameters are the input variables of a procedure, and arguments specify the values of those parameters when the procedure is called. So in PROCEDURE applyDiscount(originalPrice, discountRate), the parameters are originalPrice and discountRate. When you call applyDiscount(50.00, 0.2), the arguments 50.00 and 0.2 get assigned to those parameters, the procedure runs its block of statements, and (if there's a RETURN) it hands a value back. Parameters are what make one procedure reusable for many different inputs instead of being hard-coded for one situation.
Parameters live in Unit 3 (Algorithms and Programming), specifically Topic 3.12 Calling Procedures and Topic 3.13 Developing Procedures. They support learning objective AP Comp Sci P 3.12.A, where you write procedure calls and trace what they do, and AP Comp Sci P 3.13.A and 3.13.B, where you explain and build procedural abstraction. Parameters are the mechanism that makes procedural abstraction work. EK AAP-3.B.4 says a procedural abstraction can extract shared features to generalize functionality, and parameters are literally how you do the generalizing. Instead of writing calculateTaxAt8Percent and calculateTaxAt5Percent, you write one procedure with a taxRate parameter. This idea also matters beyond the multiple-choice exam, because the Create performance task scoring requires a student-developed procedure with at least one parameter that affects the procedure's behavior.
Keep studying AP Computer Science Principles Unit 3
Arguments (Unit 3)
Parameters and arguments are two halves of the same handoff. The parameter is the variable name in the definition, and the argument is the actual value you pass in the call. EK AAP-3.A.3 draws this exact line, and MCQs test whether you can match arguments to parameters by position.
Procedural Abstraction (Unit 3)
Abstraction means using a procedure knowing only what it does, not how it does it. Parameters are the public face of that deal. A caller only needs to know what inputs to supply, and the parameters define exactly what those inputs are.
Variable (Unit 3)
A parameter is just a variable with a special origin story. It gets created and assigned automatically when the procedure is called, rather than by an explicit assignment statement, and it only exists inside the procedure's block.
Function (Unit 3)
EK AAP-3.A.2 notes that procedures go by different names depending on the language, like function or method. Whatever the name, parameters work the same way, so what you learn about parameters in AP pseudocode transfers directly to Python, JavaScript, or block-based code in your Create task.
On the multiple-choice section, parameters show up in two main ways. First, you'll see a procedure definition like PROCEDURE calculateTotal(price, quantity, taxRate) and be asked which call statement is correct, which means matching arguments to parameters in the right order and using result ← procName(arg1, arg2) from the reference sheet to capture a returned value. Second, you'll trace a call like calculateTotal(12.99, 5, 0.08) and determine the result, substituting each argument for its parameter and walking through the statements. Parameters also matter heavily for the Create performance task. The 2023 scoring criteria for the written response awarded a point for showing a student-developed procedure with at least one parameter that has an effect on the procedure's functionality. A parameter that's listed but never actually changes what the procedure does won't earn that point.
Parameters are the variable names in the procedure definition; arguments are the actual values supplied when the procedure is called. In PROCEDURE calculateSum(a, b), a and b are parameters. In the call calculateSum(3, 7), the values 3 and 7 are arguments. A quick memory hook is that parameters are part of the definition, arguments arrive at the call. The CED separates these cleanly in EK AAP-3.A.3, and MCQs reward knowing which is which.
Parameters are the input variables of a procedure, defined in the parentheses of the procedure header (EK AAP-3.A.3).
Arguments are the actual values that fill in the parameters when the procedure is called, and they're matched to parameters by position.
On the exam reference sheet, procedures are written as PROCEDURE procName(parameter1, parameter2, ...) with a block of statements, optionally ending in RETURN(expression).
Parameters make procedural abstraction possible by letting one procedure generalize across many inputs instead of hard-coding values (EK AAP-3.B.4).
When you trace a procedure call, substitute each argument for its parameter, run the procedure's statements, and use any returned value back at the call site.
Your Create task procedure must have at least one parameter that actually affects how the procedure works, not just a decorative one.
A parameter is an input variable of a procedure, listed in the procedure's definition. Per EK AAP-3.A.3, parameters get their values from arguments each time the procedure is called, which lets the same procedure work on different inputs.
The parameter is the variable name in the definition, and the argument is the value passed in the call. In PROCEDURE applyDiscount(originalPrice, discountRate), the parameters are originalPrice and discountRate; in the call applyDiscount(80, 0.25), the arguments are 80 and 0.25.
Yes. The Create performance task scoring criteria (including the 2023 rubric's procedural abstraction row) require a student-developed procedure with at least one parameter that has an effect on the procedure's functionality. A parameter your code never uses won't count.
Yes, the AP pseudocode allows procedures that take zero or more arguments. But for the Create task specifically, the procedure you submit for credit must have at least one parameter that affects its behavior.
Mostly yes, with one difference in how they're assigned. A parameter is a variable that automatically receives its value from the matching argument at the moment the procedure is called, instead of through an explicit assignment statement, and it's used inside the procedure's block.