For context, I'm writing TypeScript, but I believe the concept works for many languages.

I have a function getFooParams(): FoodParams, that gets data that gets passed to foo later on. (It's a React-Native project that has some limitations on how the data can be passed to the native code, so this architecture seems unavoidable.)

Should the terminology be getFooParams or getFooArgs and FoodParams vs. FooArgs.

I'm leaning toward FooParams for the type, and fooArgs for instances of the type.

Update: Specific use-case example

I have a situation where I have an API client object that's responsible for formatting and sending requests to the API. Unfortunately, there are a few endpoints I have to pass off the actually requesting to a 3rd-party react-native-background-geolocation module. This module will send HTTP requests in the background without hitting my code, so I need to describe to it how to format that query. To avoid having API logic with my code that deals with the geolocation module (and because I have 3 implementations of that API client) I have a function getTimeEstimateInfo that returns the type TimeEstimateInfo to have the API client object create an object to pass on the the 3rd-party module.


3 Answers 3


A function has parameters, they have a type and a name. When you call the function, you pass arguments into those parameters. The arguments have a value (which also has a type).

See also Difference between parameter and argument on Wikipedia:

Parameters and arguments

The terms parameter and argument may have different meanings in different programming languages. Sometimes they are used interchangeably, and the context is used to distinguish the meaning. The term parameter (sometimes called formal parameter) is often used to refer to the variable as found in the function definition, while argument (sometimes called actual parameter) refers to the actual input supplied at function call. For example, if one defines a function as def f(x): ..., then x is the parameter, and if it is called by a = ...; f(a) then a is the argument. A parameter is an (unbound) variable, while the argument can be a value or variable or more complex expression involving values and variables. In case of call by value, what is passed to the function is the value of the argument – for example, f(2) and a = 2; f(a) are equivalent calls – while in call by reference, with a variable as argument, what is passed is a reference to that variable - even though the syntax for the function call could stay the same.[4] The specification for pass-by-reference or pass-by-value would be made in the function declaration and/or definition.

Parameters appear in procedure definitions; arguments appear in procedure calls. In the function definition f(x) = x*x the variable x is a parameter; in the function call f(2) the value 2 is the argument of the function. Loosely, a parameter is a type, and an argument is an instance.


Now, what are your values? Are your values describing the parameters of a function? For example, if you want to create a function in run-time, and you are specifying what parameters the function will have (not what values to pass when you call it). Or if you are using some form of reflection to know about the parameters of the function (not the values used to call it), then you want a type named after parameters.

On the other hand, if you want to represent the arguments that will be used to call a function, or you want to get an object containing all the values you got in a function call... then name your type after arguments.

See also arguments in Javascript (given that you are working in TypeScript).

  • I've updated the question for my specific use-case. Using "parameters" as reflected descriptions and "arguments" for the container of the actual values being passed makes perfect sense. I hadn't considered that a program might need to describe parameters that way (even though I've done it before). Sounds like "arguments" is the answer to my question.
    – duckbrain
    Commented Feb 27, 2020 at 16:35

I'd like to offer a different perspective. It is said that these terms come from mathematics, however, there the word argument(s) refers to the independent variable(s) of a function - the thing that can vary that is of direct interest to us given a certain problem that we want to understand or reason about. Take for example, this function:

f(x) = ax2 + bx + c

As written, this is a function of x, and in math-speak, x is the single argument. In other words, this formula indicates that you are interested in what happens as x varies (how the function behaves, what are its features, etc.). This is captured by the f(x) notation.
However, note that this designates many different functions of the same sort - what you'd call a family of functions (in this case, quadratic functions), as you can choose different values for a, b & c. Mathematicians call these parameters. The family of functions is said to be parameterized by a, b & c - and you get a concrete function by choosing some value for each parameter. One place where this comes up in application where it might make more sense to you as a programmer is in data analysis / data science, where you may want to fit a function to some data sample (i.e., to find a function that best describes a set of somewhat scattered data points, to identify a trend - e.g. occurrences of some medical condition across different age groups). The algorithms that do the fitting vary the parameters trying to minimize the error until some threshold value or a cutoff point is reached. The parameters may have certain technical meaning of their own, but the argument is what's considered the input to the function (the age, in the previous example). You could treat the function above as f(x, a, b, c), but the f(x) notation communicates that the idea is to think of it in a different way.

Note 1:
So, if your domain is mathematics (or statistics, physics, medicine, or some other field/subfield that utilizes this language), and if your users and domain experts think in these terms, you may choose to adopt the terminology to express these concepts (but in some way that's not confusing for the developers working on the project - that's where the notion of the ubiquitous language comes in).

Note however, that sometimes, these terms can have other meanings in different contexts within the same discipline (e.g. the term parameter is used in a different way when talking about parametric equations).

As a programmer, on the other hand, you would write the same function, f(x) = ax2 + bx + c, like so:

double someFunc(double x, double a, double b, double c)

or, in TypeScript:

function someFunc(x: number, a: number, b: number, c: number): number

There's no notational mechanism to distinguish the two roles, and as far as we (developers) are concerned, this is a function of four arguments. Besides, what we call a function is not necessarily the same concept as the mathematical function (we think in terms of procedures with possible side effects, they think in terms of maps between two sets), so the mathematical concepts of arguments and parameters don't necessarily translate.

Note 2:
Incorporating domain concepts here might look something like this:
function quadraticModel(x: number, parametrization: QuadraticParametrization): number

where instances of QuadraticParametrization might be objects of interest in their own right, potentially used elsewhere in the application.

As you've noted, we tend to use "parameters" and "arguments" interchangeably in an informal setting. However, even in formal settings, there's no universal agreement. "Formal setting" just means that you have explicitly stated at some point in your discussion the definitions that you are going to use consistently throughout the discussion (or the document), because it's important for the purposes of the discussion to make the distinction. This distinction is not particularly necessary in most usual development activities, though (e.g., it might be more important if you are talking about, say, compilers). So you end up with all kinds of terms: formal argument, formal parameter, actual argument, actual parameter.

There's a convention where parameters are the variables as they appear in the function signature, while arguments are the concrete values that are passed in - but that's just a convention that may or may not be used in any given setting. And even within that convention, not everyone is in agreement when it comes to details (e.g., when you pass in something by reference (or a pointer), is the argument the memory address, or the referenced object; in different contexts, it may make more sense to choose one over the other). The Wikipedia article acknowledges this ambiguity, but is itself somewhat inconsistent, as some of the citations used to back certain claims aren't using the same terminology as that suggested by the context in which they appear).

So, that's the state of things - you either have to infer the meaning from context, or check if the definition is explicitly stated, and what's the scope within which it applies.

As for your own code, if you have to use such suffixes in your type names, agree with your team on the terminology (or pick some convention if you are the sole developer), and then use it consistently throughout the codebase. However, it might be hard to stay consistent over time (especially in a team setting). Perhaps a better alternative is to dig a bit deeper and find a suitable domain concept (a term that's out there, that people already use) that can serve as a name. You generally don't have to repeat the function name in the name of the parameter type (or in the name of related functions or types); the signature tells you what needs to be passed in. It's better if the type of the parameter carries some information about what that object represents conceptually, with the parameter name clarifying the role that it plays within the function or a dependent object.

On the other hand, you can't always find such concepts in the domain, e.g., when the structures formed by your objects/types/functions are more organizational in nature, and it's not clear or feasible to model things in a different way. In that case, there might be some value in sticking to a naming convention to help guide the developers working on the code (either other people or your future self).


While writing my update, I realized I could avoid the question all together and name it something more specific to my use-case.

While, the object returned is a set of arguments for an HTTP request, it can also be referred to as a "format" for a query.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.