Interacting with the output of a function should be as predictable as invoking it.A Note on RO/ROsThe RO/RO pattern (request object / return object) is great and I recommend using it, but it introduces a new challenge: naming properties of the object(s)..In the spirit of keeping the API consistent, the objects should be well-named (see earlier section on this) and should grow only..Deprecating or renaming a property in one of these objects is a breaking change that affects consumers of the function.ConclusionBy keeping the boundaries between functions small, predictable, and well-defined, you can prevent change from propagating wildly through your program..Changes in code that do not change an API will bring their improvements for a minimal cost, as no consumer of the API will need to change..Treating function signatures as APIs enables tests to easily cover every possibility for inputs and outputs without manipulating or depending on the function’s internals or context..This leads to robust testing suites that inoculate programs against bugs.Additional Readinghttps://emptysqua.re/blog/api-evolution-the-right-way/. More details