Most projects have two types of code intermixed, code that moves data around, and code that actually does stuff with the data. Plumbing and logic. Much clarity and simplification can be gained from separating the two, at least at the function level. This gains you a number of positive effects:
Improved readability. The scope that your functions deal with is now limited. Any given function now either deals with plumbing, or logic, never both. This means the mental context needed to read and understand these functions is greatly reduced.
Functional purity. If your functions just deal with logic and don’t care where the data comes from, they can likely be pure, which makes them context-free and thus further reduces cognitive overhead of working with code.
Testability. When code is split along the logic/plumbing lines, plumbing usually becomes sufficiently simple that mistakes are highly unlikely, so tests are not required[1]. Logic, being standalone and pure, can now be tested easily if necessary by preparing canned input data.
[1] Writing tests is expensive, so ROI needs to be considered. Why would you write and maintain tests for code that is unlikely to fail?
Comments
Post a Comment