3 ms·

I think that Uncle Bob and his ilk would dispute the idea that breaking a large function into smaller functions ever makes the original function less readable.

I think that Uncle Bob and his ilk would dispute the idea that breaking a large function into smaller functions ever makes the original function less readable. They'd argue that each of the new, small functions is proven to be correct (since you'd fully unit-tested it), so its contents are of no consequence when reading the larger function. How true that is I'm not really sure.

jbrechtel 14y ago
In an OO-world function extraction usually results in private methods to a class. You (generally) don't test those directly so it doesn't necessarily result in more specific unit tests.
- maio 14y ago
  Well you can extract methods into new object where they will be public.
chadcf 14y ago
I think you have to have a good balance here. I've found following a huge method or function rather complicated, but at the same time I think I find trying to track down complicated abstractions even more complicated. If you've ever stared at a new codebase trying to track down a bug, you know the joy of grepping and following chains of methods trying to get to the part that actually matters. This may not make it technically less readable but I'd say it makes it significantly less, uh, understandable? Really, it boils down to how easy the code is to understand and maintain. Group code into logical groups. Don't break it up if the only benefit is following some arbitrary rule stating your functions should be no more than x lines long.
- rdfi 14y ago
  I believe the rule is not necessarily about having a small number of lines (that is just a consequence), it's about the method having one responsibility, only do one thing, and that thing should be understandable just by reading the method's name. The ultimate goal is that the code can almost be read as plain English. This has the consequence of making the methods smaller since they are narrow in scope. It's easier to understand a well named method with a few lines of code (and believe me, it's easier to properly name it than a method with a lot of code, since the former is focused in one task and it is easy to come up with a name that describes that task; and the latter, where the method does so many things that there's no way you can name it properly [have you ever found methods with names like DoWork and then 100 lines, I'd say that is a code-smell].
SideburnsOfDoom 14y ago
> They'd argue that each of the new, small functions is proven to be correct Yes, and when breaking up a large function, a very important thing is that you are giving a name to various steps as well as hiding details. Large undifferentiated functions just read like one damn detail after another. Picking good names greatly helps the readability.

jbrechtel 14y ago

In an OO-world function extraction usually results in private methods to a class. You (generally) don't test those directly so it doesn't necessarily result in more specific unit tests.

maio 14y ago
Well you can extract methods into new object where they will be public.

chadcf 14y ago

I think you have to have a good balance here. I've found following a huge method or function rather complicated, but at the same time I think I find trying to track down complicated abstractions even more complicated. If you've ever stared at a new codebase trying to track down a bug, you know the joy of grepping and following chains of methods trying to get to the part that actually matters. This may not make it technically less readable but I'd say it makes it significantly less, uh, understandable? Really, it boils down to how easy the code is to understand and maintain. Group code into logical groups. Don't break it up if the only benefit is following some arbitrary rule stating your functions should be no more than x lines long.

rdfi 14y ago
I believe the rule is not necessarily about having a small number of lines (that is just a consequence), it's about the method having one responsibility, only do one thing, and that thing should be understandable just by reading the method's name. The ultimate goal is that the code can almost be read as plain English. This has the consequence of making the methods smaller since they are narrow in scope. It's easier to understand a well named method with a few lines of code (and believe me, it's easier to properly name it than a method with a lot of code, since the former is focused in one task and it is easy to come up with a name that describes that task; and the latter, where the method does so many things that there's no way you can name it properly [have you ever found methods with names like DoWork and then 100 lines, I'd say that is a code-smell].

SideburnsOfDoom 14y ago

> They'd argue that each of the new, small functions is proven to be correct Yes, and when breaking up a large function, a very important thing is that you are giving a name to various steps as well as hiding details. Large undifferentiated functions just read like one damn detail after another. Picking good names greatly helps the readability.