That only works in simple cases. Most cases are simple, but the ones that matter most are the ones that are not. There is sometimes a great deal that can usefu

That only works in simple cases. Most cases are simple, but the ones that matter most are the ones that are not. There is sometimes a great deal that can usefully said, about what a function is for, that is only apparent in the context of its use. If the purpose of a() is accomplished by calling a1(), a2() and a3(), it would not be unusual for the purpose of a2(), for example, to only be understandable in the way a1(), a2() and a3() work together to satisfy the purpose of a(). If the only words you are allowed to write are the names of the functions, there is nowhere to document this interaction (especially if the name of a() is supposed to say what it does, not how it works.) The more you break down a solution into functions, the more the satisfaction of the purpose of the program becomes a consequence of how the functions interact. For an example, look at the comments to the function checkListProperties in christophilus' SQLite example [1], and consider how you would convey the same information through function naming. Then look me in the eye and tell me that's the way you write code. [1] https://www.sqlite.org/src/artifact/9711a7575036f0d3 https://www.sqlite.org/src/artifact/9711a7575036f0d3