A Functional Programming Checklist

Questions to ask in review

Is business logic in pure functions that take everything they need as arguments, including time and randomness? Are inputs left unmutated and updates done by copying or structural sharing? Are side effects confined to a thin shell? Do small, well-named functions compose into readable pipelines, with a loop where a loop is clearer? Are states modelled as discriminated unions with exhaustive matching? Are expected failures returned as Result or Option values rather than thrown or hidden in null? Is recursion bounded, laziness intentional and memoisation limited to pure functions? Have performance costs been measured rather than guessed?

The checklist

Use it during code review.

[ ] business logic in pure functions; time, randomness and config passed in
[ ] no mutation of arguments or shared state; readonly types on inputs
[ ] updates by copying the changed path (spread, Immer), not deep clones
[ ] side effects (I/O, logging, clock) only in the imperative shell
[ ] small named functions composed with pipe; loops where clearer
[ ] point-free only where it reads well; explicit lambdas for callbacks
[ ] states as discriminated unions; exhaustive switch with never
[ ] expected failures as Result/Option; exceptions for bugs only
[ ] recursion bounded or replaced by loops; generators for lazy streams
[ ] memoisation only on pure functions, with bounded caches
[ ] reducers pure; ids and timestamps created outside them
[ ] performance measured with a profiler before optimising

Adopt gradually

You do not need a new language or library. Start by making one module's logic pure and testable, then expand the pattern where it pays off.

त्वरित जाँच: Which item belongs on a functional programming review checklist?

• Reducers read the current time directly
• Every function mutates a shared global for speed
• Expected failures are returned as Result or Option values
• Deep-clone the whole state on every update