Build fluency in the vocabulary of a function whose output depends only on its own arguments.
0 / 5 completed
1 / 5
At standup, a dev mentions a function whose return value depends only on its input arguments, with no side effects like modifying external state, performing I/O, or depending on anything outside its own parameters. What is this kind of function called?
A pure function has a return value that depends only on its input arguments, with absolutely no side effects such as modifying some external variable, performing file or network I/O, or reading from anything outside its own parameters, which means calling it again with the same arguments always produces the exact same result. A higher-order function is an unrelated, orthogonal property about whether a function accepts or returns another function, not about whether it has side effects. This no-side-effects, same-input-same-output guarantee is exactly what makes a pure function's behavior fully predictable and safe to reason about in isolation.
2 / 5
During a design review, the team confirms a function has no side effects and its output depends only on its arguments, specifically so it can be safely memoized and its calls can be freely reordered or run in parallel without changing the program's behavior. Which capability does this purity provide?
This purity provides safe memoization and reordering, since a pure function's result never depends on when it's called, what order it's called in relative to other calls, or anything happening elsewhere in the program, so caching its result for a given set of arguments, or running multiple calls in parallel, or reordering them, can never change the program's overall behavior. A function whose output depends on some external mutable state could return a different result depending on exactly when it's called, which makes memoizing or reordering it unsafe. This is exactly why purity is such a valuable property to establish before applying optimizations like memoization or parallelization.
3 / 5
In a code review, a dev notices a function is documented and named as if it were pure, but its body silently reads a global configuration variable that can change between calls, meaning the same arguments can sometimes produce a different result. What does this represent?
This is a function that isn't actually pure despite being presented as one, since its output secretly depends on a global configuration variable's current value, which is external mutable state outside its own arguments, meaning the exact same arguments can produce a different result depending on what that global happened to be set to at call time. A cache eviction policy is an unrelated concept about discarded cache entries. This mismatch between a function's documented purity and its actual hidden dependency is exactly the kind of subtle bug a reviewer needs to catch, since any code that memoizes or reorders this function trusting its supposed purity will end up with incorrect behavior.
4 / 5
An incident report shows a memoization layer wrapped around a function that was documented and named as pure returned stale, incorrect results in production, because the function actually read a global configuration variable internally, and its output silently changed whenever that configuration changed between calls. What practice would prevent this?
Removing the hidden dependency on the global configuration variable, and instead passing any needed configuration explicitly as one of the function's own arguments, makes the function's output genuinely depend only on its inputs, restoring the actual purity its documentation and name already claimed, which is exactly the fix for the stale-result incident described here. Continuing to memoize the function while it still secretly reads a global internally is exactly what let the memoization layer return incorrect, stale results once that configuration changed. This explicit-argument-passing fix is the standard remedy whenever a function that's supposed to be pure turns out to have a hidden dependency on something outside its parameter list.
5 / 5
During a PR review, a teammate asks why the team insists on verifying a function's actual implementation for hidden side effects before trusting its documentation's claim that it's pure, instead of just trusting the documentation and name at face value. What is the reasoning?
A function's name and documentation can claim purity while its actual implementation secretly reads or depends on some external mutable state, and any code that goes on to memoize that function's results or freely reorder its calls based on that false purity claim can silently produce incorrect, stale, or order-dependent results without any obvious warning sign. Verifying the actual implementation directly is the only way to be certain the purity claim genuinely holds, since a mismatched claim is exactly the kind of subtle, easy-to-miss bug that a superficial read of the documentation alone would never catch. The tradeoff is the extra verification effort involved, which is a small cost compared to debugging a production incident caused by an optimization that trusted an inaccurate purity claim.