[jasonwocky]

Not really, since the dependencies between them are now explicit. Yes the stitching is its own complexity, but divide-and-conquer is a pretty time-honored approach to effective problem solving.

[jcelerier]

> but divide-and-conquer is a pretty time-honored approach to effective problem solving.

only if you can also divide and conquer the amount of persons that will dev, because now when there was one name to learn and assign meaning to, there are ten different names.

I am speaking as someone who used to have a hard limit on function length (20 lines, in Allman style :-) ) - this ended up being really harmful and creating way too complex code sometimes.

[aluth]

Of course it was harmful, you were focusing on the wrong thing. The point of having methods with no more than [insert number] lines isn't because having a method with more than [insert number] lines is inherently bad. It's because long methods are usually an indication that the method is breaking the single responsibility principle. I get the impression that a bunch of programmers read Robert Martin's work, put no thought into what he was saying about short methods, concluded that the line count was the problem, and began proliferating that idea.

To give you an example, when using Java's stream functionality, I tend to insert every method call in the chain after stream() in a new line, for readability:

  ...
  entityIds.stream()
      .map()
      .filter()
      .collect();
  ...

When I scan the method to see if it should be broken down, the fact that this code occupies 4 lines doesn't really contribute much to my decision to refactor the method into several methods, because those 4 lines are accomplishing one thing.