> I think, in general and ranked from best to worse, > > 1. Many functions, all with few arguments > 2. One function with not-that-many optional arguments > 3. One function with keyword arguments > 4. One function with too many optional arguments
I don't think any such generalization is very helpful - regardless of how one might choose to order those. > Documentation is not a problem for case 1 since small > functions with clear names and few arguments typically > requires just 1~3 lines of documentation. > > This documentation is also easy to browse, you won't have to > navigate the help buffer or search it for what an argument or > keyword does, written far below somewhere in the text. I think you're missing the point I made about a "family" of functions. Just having separate "many functions, all with few arguments" can make it more difficult to understand which is which, what's what, and when to use this one or that one. More generally, it's harder to see what the familial relations are. You can't as easily see the forest because of all the trees.
