Prompted by a recent exchange with @diana . I am formally proposing that we allow reduce. See the docs PR for details:
main ← jkuester:free_reduce
opened 08:45PM - 07 Jul 26 UTC
# Description
Our [code style guide](https://docs.communityhealthtoolkit.org/… community/contributing/code/style-guide/#avoid-reduce) has long contained instructions discouraging the use of the `Array.reduce` function. The context provided in the docs for _why_ `reduce` should not be used is that
> Most uses of reduce have more readable alternatives.
With [the nod](https://github.com/medic/cht-core/pull/11209#discussion_r3473011461) from @dianabarsan, I would like to remove this prohibition for these reasons:
1. It is standard JS code and for new contributors to the CHT code-base it is surprising that this function (and pretty much only this function) should not be used in our code-base.
2. Use of the `Array.map/filter` functions in our code-base are ubiquitous. From the perspective of readability and code-flow, `reduce` fits well along side these other functions (as intended). Its syntax/behavior is not difficult to understand (especially when used with these other Array functions).
3. In many cases in our code-base where `reduce` _could_ be used (e.g. populating a dictionary from an Array), we instead initialize the target container in one statement and then use a for-loop to populate it. This kind of state-ful imperative approach is unnecessarily verbose for many simple cases.
This is not about switching to using `reduce` for everything. But I think the same general rule for all our code should apply. Prioritize readability! If using `reduce` _improves_ readability, then use it, otherwise do not use it. :+1:
# License
The software is provided under AGPL-3.0. Contributions to this project are accepted under the same license.
Please feel free to reply here or on the PR if you have thoughts/opinions/objections/etc.
I have made my case in the PR and am happy to hear differing opinions!