What Is a Pure Function?

A pure function has two properties. First, when you give it the same arguments it always returns the same result, and it does not depend on anything outside of its parameters. Second, it causes no side effects that other code can observe. It does not change the arguments it was given, it does not modify any object or variable outside itself, and it does not do input or output work such as writing to the console, reading a file, or calling an API.

That definition has consequences that are worth spelling out. A pure function is easy to test, because you call it and you compare the result. It is safe to call again and again and in any order. It is safe to share between threads or between concurrent requests, because two calls cannot get in each other's way. And it is safe to cache, because a given input always leads to the same output, which is the whole basis of memoisation.

The payoff shows up in practice when something changes. If a function reads a global variable or reaches into a database, then changing the database changes the behaviour of the function, and you cannot test it without arranging the whole world around it. If the function takes everything it needs as arguments and returns a result, then the change stays contained.

There are two honest caveats. Strict purity is not always practical or desirable. A function that formats a date needs the current time, and the simplest way to get it is to read the clock, which is a side effect. The practical answer that many teams use is to inject the clock, or a source of random numbers, as a parameter. That keeps the logic testable while the wiring stays impure. Logging is a side effect too, so a function that logs as well as returning a value is not pure, even though it feels harmless.

The impure version reads a rate from outside, changes it, and writes to the console. The pure version takes everything it needs as arguments and only returns a value.

// Impure: it reads and writes state outside itself.
let taxRate = 0.2;

function totalWithTax(items) {
  let total = 0;
  for (const item of items) {
    total += item.price * (1 + taxRate);
  }
  taxRate = 0.3;              // a side effect: it changes shared state
  console.log('charged', total);  // a side effect: it writes to the console
  return total;
}

// Pure: the same input gives the same output, and nothing else changes.
function calculateTotal(items, rate) {
  let total = 0;
  for (const item of items) {
    total += item.price * (1 + rate);
  }
  return total;
}

const items = [{ price: 100 }, { price: 50 }];

console.log('total:', calculateTotal(items, 0.2));   // 180
console.log('total:', calculateTotal(items, 0.2));   // 180, identical every time
console.log('total:', calculateTotal(items, 0.3));   // 195

The refactor does three things. It replaces the global read with a parameter, which makes the rate explicit at every place where the function is called. It removes the change to the global, so calling the function cannot alter the behaviour of anything else. And it moves the logging out, so the function only returns a value and the caller decides whether to log, and how.

Notice that the second call returns exactly the same number as the first one. That is the test for purity. If you call it twice and you get the same answer, and nothing outside of it changed, then the function is pure with respect to its inputs.

There is one subtlety worth mentioning. The function still does not make a deep copy of the items that it receives. If a caller changes an item after the call, then the result of a later call can be different. Strictly speaking, a function that reads nested properties of its arguments can be affected by a change from outside. Most teams treat this as acceptable, and the practical answer is to keep the shape of your data simple and to make a copy before you change anything.