I just recently realized why named parameters is such a terrific pattern. If used correctly, it can provide clarity to code that makes both reading and parsing its intent much clearer.

Named parameters in JavaScript

Truth be told, JavaScript does not actually support named parameters. We just simulate it. We do this by passing a single object to a function instead of multiple parameters. If you are using Babel, you can also use destructuring to shorten the amount of code required.

Now that we know how, we need to know why. Let me try to demonstrate this with a simple example.

Simple example

Lets say we have a class Child that takes two Parents as its arguments.

With this class, creating a new child would be as simple as this

Pretty easy, right?

Or is it?

You may have already noticed it, but I’ve made a mistake in the above code. I’ve got the order of the parameters wrong. A fairly easy mistake to make.

I will most likely quickly discover my error once I run this code, but it will make development time take just a little longer. Also, later down the line, someone will have to review my code. When reviewing, they will also have to check if I got the order correct.

Lets see what happens when I use named parameters in my Child constructor.

Adding a total of 4 curly braces has saved us any ordering issues we might of had. All you now need to remember is to pass in an object with a Mother and a Father. This is great, but not the reason why I use named parameters. The part that I am interested in, is something else.

We have established a connection between the variable names used by the caller and those used by the callee.

This was my big Aha! moment. We have explicitly mapped dad to father and mum to mother. We have created a link between our code and the constructor code. Why this is significant may not be obvious at first, but try to imagine this: Imagine that English is not your native language. Would you still know that dad was the same thing as a father? Would you be surprised when you saw the the variable dad being used as input for the variable father?

Remember, the above is a trivial example created for this post. So try to imagine how this pattern would look in your own code. Could it help improve readability when dealing with some domain specific code? (PS: I’ve included a few real world examples at the end of this post).

I personally have started using named parameters much more often after I realized the points above. I find the resulting function definitions and function calls to be more readable and maintainable. Especially when I’m reading the code on Github without my trusty IDE

But

With great power…

As with everything, this pattern can easily be abused.

As long as hugeObject contains a father and mother property, the code will work. However, it won’t be very readable for the developer that has to debug this some day. To avoid this issue, I always try to be explicit in what I am actually passing to my functions.

Another issue with this pattern is that changing the variable names used in our functions would not be as trivial as before. This may or may not be a good thing. In the cases where you are changing the purpose or meaning of a variable, it might be a good thing. In all other cases, its probably a bad thing. I’m mostly using TypeScript these days where renaming variables can be done automagically. So this is not an issue for me. It will however be an issue for you if you are in a JavaScript project.

Wrapping up

Too wrap things up, I’ve included a few examples below for you to compare. Use them to decide for yourself if and when named parameters actually provide any value. Pretend that you have never seen the functions parseInt, slice and reduce when judging.

Thanks for reading and I hope you enjoyed it.