Which Of The Following Is Not A Parameter

You're staring at a multiple-choice question. Three options look familiar. Consider this: one feels off. You pick it, move on, and never think about it again — until the next exam, the next code review, or the next time someone uses "parameter" and "argument" interchangeably in a meeting and you're not 100% sure if they're wrong or you are.

Here's the thing: most people don't actually know what a parameter is. They know what it looks like. They've seen function(x, y) enough times to recognize the pattern. But ask them to distinguish a parameter from an argument, a variable, a hyperparameter, or a query string — and the room goes quiet.

This article isn't about memorizing definitions. Because once you see the pattern, the "which of the following is not a parameter" questions stop being tricky. It's about building a mental model that holds up across programming, statistics, APIs, and machine learning. They become obvious.

What Is a Parameter, Really?

Strip away the jargon and a parameter is just a placeholder*. So the value that fills it? And the slot has a name, a type (sometimes), and a scope. A named slot that waits for a value. And that's it. That's something else entirely.

In a function definition, parameters are the names inside the parentheses:

def calculate_area(width, height):
    return width * height

width and height are parameters. They exist only in the function signature. They don't hold real data until someone calls the function.

Now call it:

calculate_area(5, 10)

5 and 10 are arguments*. They're the actual values passed in. The parameters receive them. This distinction — parameter vs. argument — is the single most common confusion point in programming. Parameters are the declaration*. Arguments are the invocation*.

But "parameter" doesn't stop at functions.

Parameters in Statistics

Here, a parameter is a numerical characteristic of a population*. The mean height of every adult on Earth? That's a parameter. Still, you'll never know it exactly. But you estimate it with a statistic* — the mean height of your sample. Because of that, the parameter is the truth. The statistic is your best guess.

This trips people up because in code, "parameter" feels like an input. In statistics, it's an unknown constant* you're trying to uncover. In practice, same word. Completely different mental model.

Parameters in Machine Learning

Now it splits again. Think about it: model parameters (weights, biases) are learned from data. Hyperparameters (learning rate, batch size, number of layers) are set before* training. Now, both get called "parameters" in casual conversation. Only one is actually learned. The other is a configuration choice.

Call a hyperparameter a "parameter" in a paper review and someone will correct you. Call a learned weight a "hyperparameter" and they'll wonder if you've ever trained a model.

Parameters in APIs and URLs

https://api.example.com/users?limit=50&offset=100

limit and offset are query parameters. They're key-value pairs in the URL. In real terms, they behave like function parameters — named slots that accept values — but they live in HTTP requests, not code. The server reads them, validates them, and uses them to shape the response.

Different context. Same pattern.

Why the Confusion Exists

The word "parameter" comes from mathematics — para-* (beside) + metron* (measure). A quantity that defines a system but isn't the primary variable. In parametric equations, x = f(t), y = g(t), the parameter t drives both x and y. It's the hidden knob.

Computer science borrowed the term. Then machine learning. On top of that, then statistics. Each field kept the core idea — a configurable value that shapes behavior — but added its own constraints, lifecycle, and terminology.

The result? A word that means slightly different things depending on who's talking. And a whole lot of "which of the following is not a parameter" questions that exploit the ambiguity.

The Pattern: What Makes Something a Parameter

Across every domain, three things are true:

1. It has a name — you refer to it by identifier, not by value
2. It accepts a value — either passed in, learned, or configured
3. It influences behavior — changing it changes the output, result, or model

If all three hold, it's a parameter. If one breaks, it's something else.

Let's test this against the usual suspects in those trick questions.

Common "Not a Parameter" Candidates

1. Arguments / Actual Parameters

This is the classic. So " The answer: 42. In practice, it has no name in the caller's scope. The question shows a function call: foo(42) and asks "which is not a parameter?It's an argument. It's a value, not a slot.

But wait — some languages do call these "actual parameters" and the definition-site names "formal parameters." The terminology varies. the value. The slot vs. The distinction doesn't. That's the line.

2. Local Variables

def process(data):
    result = data * 2
    return result

result is a local variable. Consider this: it's created inside. It has a name. It holds a value. No caller passes result. But it doesn't accept* a value from outside. It's not a parameter.

3. Return Values

def add(a, b):
    return a + b

The sum a + b is computed and returned. Still, parameters are inputs (in the broad sense — things that flow in to shape behavior). It's an output. Return values flow out.

4. Constants

MAX_RETRIES = 3

def fetch(url):
    ...

MAX_RETRIES is a constant. It has a value. Also, you don't pass it. It has a name. But it doesn't accept* a value — it's fixed at definition time. You don't configure it per call. It's not a parameter.

5. Hyperparameters (in the strict ML sense)

This one's controversial. And in machine learning, hyperparameters are parameters of the training process. But they're not model parameters*. Plus, the weights and biases are learned. The learning rate is set.

If the question is "which is not a model* parameter?Plus, " — the learning rate wins. Now, if it's "which is not a parameter at all*? " — the learning rate is a parameter (of the optimizer, the training loop). Context decides.

If you found this helpful, you might also enjoy 41 months is how many years or simple interest formula and compound interest formula.

6. Statistics (Sample Mean, Sample Variance)

In statistics, the sample mean x̄ is a statistic*. And the population mean μ is a parameter*. So they look similar. One comes from data. The other defines the distribution the data came from.

If a question asks "which is not a population parameter?This leads to " and lists x̄, s², μ, σ — the first two are statistics. The last two are parameters.

7. Environment Variables

export DATABASE_URL="postgres://..."

DATABASE_URL is an environment variable. It's a named value. It's configuration, yes. So it influences behavior. Parameter? So naturally, the program reads it implicitly. But it's not declared as a parameter anywhere. Debatable.

or "environment variable," not "parameter." The distinction? Day to day, parameters are explicit contracts. Environment variables are implicit dependencies.

8. Global Variables

cache = {}

def get(key):
    return cache.get(key)

cache is global state. It’s mutable, shared, and accessible without being passed. So naturally, a parameter is passed*. A global is reached for*. That reach makes testing hard and reasoning harder. It’s the anti-parameter.

9. Closure-Captured Variables

def make_multiplier(factor):
    def multiply(x):
        return x * factor  # 'factor' captured from enclosing scope
    return multiply

factor looks like a parameter to multiply. Which means it isn’t. It’s a free variable bound at definition* time, not call* time. multiply takes one parameter: x. factor is baked in. You can’t change it per call without making a new closure.

10. self / this (The Implicit Parameter)

This is the trickiest one. In obj.In practice, method(arg), arg is explicit. obj (becoming self/this) is implicit.

• Python: Explicit in definition (def method(self)), implicit in call. It is a parameter.
• Java/C++/C#: Implicit in both. The spec calls it a "hidden parameter" or "implicit object parameter."
• JavaScript: this is contextual magic, not a declared parameter.

If the question is "what does the function declare*?" — the object reference is passed in all of them. Know the language spec. " — self counts in Python, not in Java. If it's "what does the caller pass*?Know the question's frame.

The Litmus Test

When the wording gets slippery, apply this filter:

Why the Pedantry Matters

It’s not about winning trivia night. It’s about mental models.

• Refactoring: "Extract Parameter" works on 42 (magic number) or MAX_RETRIES (constant). It fails* on result (local) or cache (global). You can only parameterize what can vary per call*.
• Testing: Parameters are your seams. You control them. You mock them. You assert against them. Globals, closure variables, and environment variables? Those require contortions—monkeypatching, dependency injection frameworks, dotenv hacks.
• Concurrency: Parameters (especially immutable ones) are thread-safe by default. Shared globals are not. Captured variables in closures? Only safe if immutable or confined.
• Serialization / RPC / API Design: You serialize arguments* (the values). You define parameters* (the schema: names, types, constraints). Confusing the two leads to "why is null showing up in my JSON?" bugs.

The Final Distinction

A parameter is a promise* of variability.

It says: *"This function has a shaped hole. The shape is fixed (name, type, position). You fill it. The content changes.

Everything else—constants, locals, globals, returns, config, captured state—is either fixed structure or implicit context.

So the next time you see "Which of the following is not a parameter?", don't just pattern-match syntax. Ask: **Does this represent a slot designed to accept a caller-provided value?

If the answer is no—whether it’s a 42, a result, a MAX_RETRIES, a DATABASE_URL, or a self in a language where it’s implicit—it’s not a parameter.

And that precision? That’s the difference between code that runs* and code you can reason about*.