One criterion for decomposition into functions is to mimic the structure of the problem domain. This makes it easier to check against the domain, to reason abou

One criterion for decomposition into functions is to mimic the structure of the problem domain. This makes it easier to check against the domain, to reason about one in terms of the other, and to extend. It's especially helpful for interactions with problem domain experts. A "domain" includes math. Efficiency may require a different structure - note though that when efficiency trully is paramount, it licenses outright barbarism. Another approach is "disproportionate simplicity", and works out similarly to an abstraction, something of a DSL. If you can modularize functionality, such that that aspect becomes much simpler, do it. Note that it might not solve the whole of that problem (like the core of git is a "stupid content tracker", it solves the part it does tackle with simplicity disportionate to the alternatives; but that simple core doesn't solve everything). It's about where to draw bounardies (between modules, with functions being one kind of module). Yet another is the traditional criterion, based on likelihood of change: boundaries between modules [functions] should be unlikely to change; the stuff that is likely to change should be "hidden" within a module [function]. Unfortunately, I've found prediction to be tricky, particularly when it concerns the future of programs.