Parameters, defaults and named arguments

What does true mean?

Here is a real line from somebody's app:

showDialog("Delete note?", true, false, 2)

Everything about it works. Nothing about it is readable. What is true? What is false? Is 2 a count, a style, a timeout?

To find out you have to go and open the function definition — which means the call site is lying to you about how simple it is. This lesson is about two small Kotlin features that fix exactly this, and they will change how you write every function from here on.

1showDialog(
2  message = "Delete note?",
3  cancelable = true,
4  destructive = false,
5  buttons = 2
6)

Same call. Nothing to look up.

Several parameters

A function can take as many inputs as it needs, separated by commas. Each one gets a name and a type:

1fun area(width: Int, height: Int): Int {
2  return width * height
3}
4
5fun main() {
6  println(area(3, 4))
7}

By default, arguments are matched by position: the first value goes into the first parameter. That is fine here, because both are Int and multiplication does not care which way round they go.

Now consider this:

fun move(from: Int, to: Int) { }

Swap those two at a call and Kotlin cannot help you. Both are Int, both are valid, and your piece moves backwards. This is the bug that named arguments exist to prevent.

Default values

Put = something after a parameter and it becomes optional:

1fun order(drink: String, shots: Int = 1) {
2  println("$drink with $shots shot(s)")
3}

Now both of these work:

1order("Latte")        // Latte with 1 shot(s)
2order("Latte", 2)     // Latte with 2 shot(s)

That is a default argument. The value is used whenever the caller does not supply one.

This matters more than it looks. Without defaults, the usual answer is to write the same function three times with different numbers of parameters — three bodies to keep in step, three places for a bug to hide. One function with defaults replaces the lot.

A default can be anything that produces a value, including a calculation, and it is worked out fresh on each call that needs it.

Named arguments

At the call, you may write the parameter's name before the value:

order(drink = "Mocha", shots = 3)

That is a named argument. It buys you two things.

Readability. order("Mocha", 3) needs the definition to decode. order(drink = "Mocha", shots = 3) does not.

Skipping. Once you are naming things, you can leave out any parameter that has a default, even one in the middle:

1fun order(
2  drink: String,
3  shots: Int = 1,
4  oat: Boolean = false
5) {
6  println("$drink, $shots shot(s), oat=$oat")
7}
8
9order("Latte", oat = true)

That gets a one-shot latte with oat milk. Without the name, there would be no way to say "skip the middle one".

Named arguments also free you from the order:

order(shots = 3, drink = "Mocha")

There is one rule about mixing the two styles: positional arguments must come first. Start naming and you should keep naming. Go back to positional after a name and Kotlin refuses with Mixing named and positional arguments is not allowed.

When to name

You do not need names everywhere. area(3, 4) is perfectly clear. A good habit:

• Always name a Boolean argument. true on its own never means anything at a call site.
• Always name when two neighbouring parameters share a type, like move(from = 1, to = 5).
• Name anything you are skipping past, because you have no choice.
• Otherwise, if the value reads obviously, leave it positional.

One function, four ways to call it