Tools for working with arrays

Up to now, handling an array meant writing a for. Start the number at 0, raise it by one until length, take things out with array[i]. It works, but you write the same frame every time, and it is easy to write wrong. Turn one < into a <= and off it goes looking for an item that is not there.

What this chapter teaches you are the tools that shoulder that boilerplate for you. It is also the discovery that there are, in truth, only a few things you ever want to do to an array.

• do the same thing to all of them — work through one at a time
• keep only the ones that match — narrow down
• rebuild the contents into a new array — convert
• find the first one that matches — search

If what you want is one of those, the matching tool writes it in one line. Freed from keeping the number, what you want comes out in the code as it is. Ten lines of for becomes one, and the intent is clear the moment you read it.

The distinction worth holding on to here is whether it changes the original array or makes a new one. The narrowing and converting tools leave the original alone and send back a new array. The original data does not get rewritten behind your back, so you are never stuck later wondering "what was it before?". Writing without rewriting data in place is remarkably good for keeping bugs down.

These tools are handed things in a slightly odd way. You pass the work itself as an argument. You write it as "please apply this work to each item of this array". It may throw you the first time you see it. What it really is comes in the next chapter, so here just accept "that is how these are written" and get to where you can use them.

The tools' other strength is that they join up. "Narrow by a condition, rebuild the contents, then show them in order" can be written as one run. The flow of the work lines up plainly from top to bottom, so a reader follows it left to right and sees what is happening. Compare that with an if inside a for with something further inside it, and the difference in clarity is large.

Some things that trip people up. The converting tool always sends back a new array, so without a variable to catch it the result is left nowhere. When "it runs but nothing comes out", check whether you threw the returned value away.

Another one: the tool that only works through them one at a time sends nothing back. That is easy to mistake as well. Fine if you only want to show things, but if you want to collect a result, use the converting tool. The knack is deciding up front: "do I want to show, or do I want a new array?"

In real code you see these far more often than for. Not being able to read them means not being able to follow other people's code; being able to write them makes your code shorter and safer. This chapter pays for itself.

That said, for is not bad. When you want to break out partway, or run on a complicated condition, for writes more plainly. You have gained tools, not lost the old one.

The names carry meaning too. Knowing the original words behind "map", "filter" and "reduce" gives your memory something to catch on.

The knack when learning is to write it with for first and then swap in the tool. Go along checking that the result is the same and what the tool is doing inside settles into place. Rather than rote learning, you end up using it knowing "this is basically that shape of for".