Bundle up work into functions

Where a variable was the machinery for "giving a value a name", a function is the machinery for giving work a name. That is the whole theme of this chapter, but the effect is large. From here on, most of the code you write is the inside of a function.

Why do you need one? Say you have the same work written in three places. When the spec changes, all three have to change. Forget one and that one stays on the old behaviour, and bugs like that are hard to find. Gather the work into a function and there is always just one place to change.

A function has three characters in it: the caller, the value handed in and the value that comes back. Take them in turn.

First, defining and calling. Write function greet() { ... } to gather the work, and greet() to run it. Defining it makes nothing happen; only calling it runs the inside. This is where people muddle themselves first.

Next comes the argument, the machinery for handing a value into a function from outside. Settle the catching name as in function greet(name), then hand the actual value over at the call as in greet("Yui"). It is thanks to this that you can reuse one function with different values as often as you like.

Then the return value. return sends a result back out of the function. What comes back can be caught where you called from, so you can write const total = sum(3, 5). The difference between return and console.log is one to get straight. console.log only puts something on the screen and the value is left nowhere. return hands the value to the caller, so it can go into later sums. "Showing" and "sending back" are different things.

Three ways of writing a function come up: the function declaration, the function expression, and the arrow function (=>). All three do the same job. Current code shows arrow functions a lot, so do at least get to where you can read them.

Last, scope. A variable made inside a function can only be seen inside that function. You cannot touch it from outside, and it cannot clash with an outside variable of the same name. This is not an awkward restriction; it is the machinery that lets you reuse a function with confidence. Because whatever it does inside is guaranteed not to affect the outside, a function stands up as a part.

The worry of "where do I cut a function?" also shows up here. The guide is whether you can name it. If you can say in a few words what the work does, it can be a function. If all you can say is "various things", the cut is still too big. When no good name comes to mind, you are usually making one function do two jobs.

The other guide is length. A function that does not fit on the screen is usually better split. There is no rule about how many lines, but a function you have to scroll to see does not fit in your head while you read it.

Learn functions and you can write code as a combination of small parts. Rather than writing a long stretch in one breath, you cut it into meaningful units and name them. Both readability and how easy it is to fix start changing here.

One hint in case you get stuck. When a function does not behave as you meant, check the entrance and the exit. Show the argument it caught at the top of the function. Show the value it is about to send back, just before the return. Roughly speaking, those two places are where you find the value that is not what you assumed.

And a practical note: every chapter from here is built on top of functions. Next chapter's classes are "functions gathered together", and what you hand to the array tools is a function. Go on with functions left vague and you will certainly be coming back. When your hands stop, come back to this chapter without a second thought.