As I’ve begun writing Tidy Together? (paying subscribers are seeing draft chapters), I’m uncovering tidyings I missed in TF?. Here’s one:
Pattern: You see the same parameters passed through several levels of the call graph but they appear in different orders.
Transformation: Tidy functions you encounter to use the canonical order. You might do this as you are reading when the difference in order confuses you. You might do this before (or after) you modify the function.
When most of the code base is using the canonical order, take one of those Friday afternoons & reconcile the rest.
Another option, if the same list of parameters is used in many places, think about grouping them into one meaningful struct/object.
for example instead of `get_users(offset int, limit int, sort_by string)` -> `get_users(filter obj)`
Definitely valuable (and as Kent said, mentioned before), but there are some cases where the parameters that serve similar purposes across a loosely related family of functions shouldn't naturally be bundled together, or at least that feels awkward to me, and so "canonical" order helps you remember how to use / read these functions.
A concrete example might be the `itertools` functions in python, which often accept an iterator (roughly, a lazy stream, if you're not familiar with the terminology). The *usually* (but sadly not always) take the iterator argument last, ie
- map(func, iterator): apply the function to each item in the stream
- filter(predicate, iterator): only pass on items that don't keep the stream
- takewhile(predicate, iterator): pass on the prefix of the stream for which predicate is true
and so on. This sort of consistency is quite helpful in my view.