Functions — naming a recipe

The same six lines, in four places

Imagine a dice game. When a player wins you want to print a little banner:

1println("*******")
2println("YOU WIN")
3println("*******")

Fine — until you need the same banner in four places. Now the same three lines exist four times. Change the stars to hyphens and you have four edits to make, and you will forget one.

There is a better move: give those three lines a name.

1fun banner() {
2  println("*******")
3  println("YOU WIN")
4  println("*******")
5}

Now anywhere in the program you write banner() and all three lines run. Four places, one definition. Change it once and every use changes with it.

Making one

1fun greet() {
2  println("Hello!")
3}

Four pieces, left to right:

• fun — the keyword that says "a function starts here".
• greet — the name. Same rules as any other name, and by convention it starts with a verb, because a function does something.
• () — the round brackets. Empty for now; Lesson 1.9 fills them.
• { ... } — the body: the steps that run when it is called.

To run it, write its name with brackets:

1fun main() {
2  greet()
3  greet()
4}

That prints Hello! twice. The brackets are how Kotlin knows you mean do it now rather than just naming it.

Handing something in

A function that always does exactly the same thing is limited. Give it a parameter and the same recipe works on different values:

1fun greet(name: String) {
2  println("Hello, $name!")
3}

name: String says: this function needs one piece of information, it is called name inside the body, and it must be a String. Now the call must supply one:

1greet("Ada")
2greet("Grace")

The value you hand over is an argument. Two words for two sides of the same handover: the parameter is the slot in the definition, the argument is the value at the call.

Leave the argument out and Kotlin says No value passed for parameter 'name'. Hand over the wrong kind and it says Type mismatch. The type on the parameter is a contract, and both sides are held to it.

Handing something back

So far our functions have done things. Often you want one to work something out and give you the answer:

1fun double(n: Int): Int {
2  return n * 2
3}

The : Int after the brackets is the return type — a promise about what comes back. Inside, return is the word that actually hands it over, and it ends the function immediately: nothing after a return runs.

Now double(21) is not an instruction, it is a value. You can use it anywhere a number belongs:

1println(double(21))
2val total = double(5) + double(10)

If a function returns nothing, you write no return type at all. Kotlin quietly calls that type Unit; you will see the word in error messages, and now you know what it means: "nothing useful comes back".

1fun double(n: Int) = n * 2
2fun isEven(n: Int) = n % 2 == 0

Why bother?

Beyond avoiding repetition, functions do three quieter things that matter more as programs grow:

1. They name an idea. isEven(n) says what it means. n % 2 == 0 makes the reader work it out. The code becomes the documentation.
2. They give you one place to fix things. A bug in a function is one bug. The same code copied five times is five bugs, and you will fix four.
3. They keep their mess to themselves. Names declared inside a function vanish when it ends — that is scope again. A function cannot accidentally trample a name used somewhere else.

Aim for functions that do one thing and are named after that thing. If the name needs the word "and", it is probably two functions.

A complete program, stepped through