> Proponents of small functions argue that you don't have to read more than the signature and name of a function to understand what it does; it's obvious what a function called last that takes a list and returns an optional value does.
I used to be one of those proponents, and have done a 180.
The problems are:
1. The names are never as self-evident as you think, even if you take great care with them.
2. Simply having so many names is an impediment in itself.
The better way:
Only break things up when you need to do. This means the "pieces" of the system correspond to the things you care about and are likely to change. You'll know where to look.
When you actually need an abstraction to share code between parts of the system, create it then.
I used to be one of those proponents, and have done a 180.
The problems are:
1. The names are never as self-evident as you think, even if you take great care with them.
2. Simply having so many names is an impediment in itself.
The better way:
Only break things up when you need to do. This means the "pieces" of the system correspond to the things you care about and are likely to change. You'll know where to look.
When you actually need an abstraction to share code between parts of the system, create it then.