Tejas Manohar

@tejasmanohar

An Argument for Named Parameters

When working with large and/or unfamiliar codebases in dynamically typed languages, I often come across function calls and don’t know which parameter represents what without looking at the function implementation. Let’s take the following call for example-

rewardUsers(user, this, 'waitlist')

That’s right! You have no clue what those parameters signify. What if we changed the picture some by introducing a concept many novice programmers are unfamiliar with — named parameters?

rewardUsers(inviter: user, invitee: this, source: 'waitlist')
That’s an extra 26 characters!

So what? I’m not counting the time you saved by understanding the code at a first glance, but it’s more than it takes me to type 26 characters.

But what languages actually support named parameters?

For this, I’ll refer to the Wikipedia article on the subject, where it states:

Named parameters are explicitly supported in many languages: a non-exhaustive selection of examples would include Ada, C# 4.0+, ColdFusion, Common Lisp, Scala, Kotlin, Mathematica, PL/SQL, Python, R, Smalltalk, Fortran, Visual Basic, IDL, Swift and Objective C.

I find the C#’s optional named parameters very useful. In essence, it allows you to pick and choose when to use named parameters and when not to without doing any extra work.

class NamedExample {
static void Main(string[] args) {
Console.WriteLine(CalculateBMI(123, 64));
Console.WriteLine(CalculateBMI(weight: 123, height: 64));
Console.WriteLine(CalculateBMI(123, height: 64));
}
    static int CalculateBMI(int weight, int height) {
return (weight * 703) / (height * height);
}
}

Often, languages evolve to add features like this. For instance, Ruby 2.0 introduces keyword arguments to the language as demonstrated in the following example.

def calculate_total(subtotal:, tax:, discount:)
subtotal + tax — discount
end
calculate_total(subtotal: 100, tax: 10, discount: 5)

Fortunately, even in some languages that don’t support named parameters, you can implement them yourself. For example, ES6's Enhanced Object Literal and Destructuring features inspired me to start using named parameters through objects frequently in JavaScript. Let’s look more into this-

function rewardUsers({ inviter, invitee, source }) {
// ...
}
rewardUsers({ inviter, source, invitee: this })
// ES5 equivalent-
// rewardUsers({ inviter: inviter, source: source, invitee: this)

In the above example, I use an object instead of individual value arguments to create named parameters. The shorthand syntax ES6 introduces makes it much easier not to be repetitive. For example, if you already have the variable inviter defined in scope and want to pass it into a function that accepts inviter as one of its object keys, you do not need to write { inviter: inviter } but just { inviter }.

Other languages, such as Elixir, Rust, and Python, also support destructuring and thus, allow you to create named parameters.

When should I use named parameters?

This is a common question whenever introducing a new feature. Personally, if possible, I almost always use named parameters when crafting functions with multiple arguments.

Utilize named parameters to improve code readability. Just my 2¢.

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.
To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.
If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!

More by Tejas Manohar

Topics of interest

More Related Stories