Pure functions and side effects

First question: called twice with the same inputs, does it give the same answer both times? Second question: when it runs, does anything outside it change?

A function that answers yes to the first and no to the second is called pure. That is the entire definition, and it is worth learning as those two questions rather than as a slogan, because the questions are what you actually apply when reading code.

Purity is not a badge of quality and it is not all-or-nothing virtue. It is a property, like being sorted. Knowing which of your functions have it tells you which ones you can move, reuse, cache and test without thinking hard.

A side effect is any change a function makes to the world outside itself. The two you can already produce are assigning to a variable declared outside the function — lesson five's bug — and printing with console.log, which changes what is on the screen.

Later you will meet bigger ones: writing a file, sending a request over a network, changing a shared collection that somebody else is holding. They differ in scale, not in kind, and they all break the same promise: that calling the function does nothing except produce an answer.

Printing being a side effect surprises people, because it feels harmless. It is harmless in the sense that nothing breaks, and it is a side effect in the sense that matters: the function did something you cannot see from its return value, and running it twice is not the same as running it once.

A function gives different answers to the same question when it reads something that changes underneath it. Three usual culprits: an outer variable that other code edits, the current time, and randomness.

Math.random is the clearest case. It takes no arguments and returns a different number nearly every time, by design — that is its entire job. Any function that calls it inherits that unpredictability, no matter how ordinary the rest of it looks.

This is not an argument against random numbers or clocks. Programs need them. It is an argument for knowing exactly which of your functions contain them, because those are the ones that cannot be tested by comparing against a fixed expected answer.

Testing a pure function is: call it, compare the answer. No setup, no cleanup, no ordering, no worrying about what the last test left behind. That is the entire reason the practice is worth cultivating, and it applies to every test you will write in module eleven.

You have been on the receiving end of this all module. Every exercise here is graded by calling your function and comparing what came back — which only works because the contracts were written to be pure. The two tests you have met that check something else, that currentScore is untouched and that receipt is still empty, exist precisely because impurity is what they are guarding against.

The same property helps far beyond tests. A pure function can be moved to another file, called from anywhere, called twice, or skipped when its answer is already known, and none of that changes the behaviour of the program. Impure ones have to be handled carefully in all four cases.

A program with no side effects does nothing observable. It cannot print, save, send or display. So the goal is never to eliminate effects — it is to be deliberate about where they live.

The shape to aim for: the calculation is pure, and a thin layer around it does the reading and the printing. Work out the total in a function that only takes numbers and gives back a number; print it in the line that calls that function. The interesting part is then testable, and the untestable part is small enough to read in one glance.

You can see this in your own exercises. safeDivide worked out an answer and returned it, and it was the surrounding code that printed. That was not decoration — it is what let five one-line tests pin the behaviour down completely.

Accumulating into an outer variable. The function works once, and every call after that starts from a value the previous call left behind. You met this in lesson five, and it is the single most common version.

Printing instead of returning. The value appears on screen, so the function looks finished, but the caller received nothing and the output cannot be tested against anything. Return the value; let the caller decide whether it deserves printing.

Reaching for the clock or the random number generator in the middle of a calculation. Take the value as a parameter instead, and let whoever calls you produce it. The calculation stays testable, and the unpredictable part moves to one visible place — which is also how the tests in module eleven get to control it.

A pure function gives the same answer for the same inputs and changes nothing outside itself. Assigning to outer variables and printing are both side effects; reading the clock, randomness or a variable that others edit breaks the same-answer half. Purity is not a moral position — a program with no effects does nothing — but keeping the calculations pure and the effects at the edges is what makes code that can be tested, moved and trusted.