[blago]

> 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;

Although this is often the case, the style of the program can change things significantly. Here are a few, not so uncommon, examples where it starts to break down:

1. When you’re crafting algorithms, you might try to keep code blocks brief, but coming up with precise, descriptive names for each 50-line snippet can be hard. Especially if the average developer might not even fully understand the textbook chapter behind it.

2. At some point you have to build higher than "removeLastElementFromArray"-type of functions. You are not going to get very far skimming domain-specific function names if don’t have any background in that area.

More examples exist, but these two illustrate the point.

[K0nserv]

Both examples stem from not understanding the problem well enough I think. My best work is done when I first write a throwaway spaghetti solution to the problem. Only through this endeavour do I understand the problem well enough to effectively decompose the solution.

[nuancebydefault]

You understand your final fine grained code after your 'spaghetti' intermezzo. Others and your future you, probably less so.

[K0nserv]

My point is that the factoring and abstractions one produce after the spaghetti intermezzo will be better than a blind stab at them; a greater understanding of the problem helps.

[nuancebydefault]

Agree that intermezzos - even of the spaghetti kind - help understanding.

I thought this thread was more about (non) maintainability of code consisting of many procedures for each of which names are to be found that will make their usage self-explaining.

From my experience, simple API's with complex and often long implementations can be very well suited. As long as those are low on side effects and normally DRY, as opposed to puristicly DRY.