3 ms·

I don't find that surprising at all. For a given piece of functionality, if it is spread across more methods, it means: - more methods to look at, and more thi

by pdubroy 18y ago

I don't find that surprising at all. For a given piece of functionality, if it is spread across more methods, it means: - more methods to look at, and more things to hold in your short term memory - more (possible) entry points to any given piece of code, so more things to test, and greater possibility of error - more lines of code to accomplish the same task - harder to grok the overall behaviour/capabilities of a class And most of my experience with big OO libraries is with the supposed best cases: Smalltalk class libraries (Squeak and IBM) and the Eclipse framework.

gruseom 18y ago
Those are great points. Here's one issue that I think is lurking in all this. Even agreeing that a large function is easier to read than, say, 10 small ones, it doesn't follow that a system written that way is easier to understand. You still have the problem of how to factor the system into large functions as opposed to small ones - a question that is not addressed by this discussion (or, I'll bet, by the research). And it's a big problem, because complex systems usually have a great deal of intertwining, partly-but-not-completely overlapping functionality. If you could factor all this into a few large functions, you'd probably get something more readable, but in most cases you can't. So in order to build a well-factored system (with minimal duplication, separated concerns and so on) you carve things into smaller pieces that can then be cobbled together to create the various behaviors you need. (At least, that's how you do it in OO.) So the business of function length plays out quite differently at the system level than it does at the function level. The function level is easier to discuss and to study, but what matters in practice is the comprehensibility of the system as a whole. That's why your caveat, "for a given piece of functionality" is a very well-placed one. You're presupposing that the functionality has already been carved into pieces.

by pdubroy 18y ago

gruseom 18y ago

Those are great points. Here's one issue that I think is lurking in all this. Even agreeing that a large function is easier to read than, say, 10 small ones, it doesn't follow that a system written that way is easier to understand. You still have the problem of how to factor the system into large functions as opposed to small ones - a question that is not addressed by this discussion (or, I'll bet, by the research). And it's a big problem, because complex systems usually have a great deal of intertwining, partly-but-not-completely overlapping functionality. If you could factor all this into a few large functions, you'd probably get something more readable, but in most cases you can't. So in order to build a well-factored system (with minimal duplication, separated concerns and so on) you carve things into smaller pieces that can then be cobbled together to create the various behaviors you need. (At least, that's how you do it in OO.) So the business of function length plays out quite differently at the system level than it does at the function level. The function level is easier to discuss and to study, but what matters in practice is the comprehensibility of the system as a whole. That's why your caveat, "for a given piece of functionality" is a very well-placed one. You're presupposing that the functionality has already been carved into pieces.