[ilbe]

"If you find your testers splitting up functions to support the testing process, you’re destroying your system architecture and code comprehension along with it. Test at a coarser level of granularity."

What? Splitting up large functions into smaller, well-named units destroys code comprehension?

[route66]

If your code turns into 30 one-liners with 30! unforeseen possible calling combinations thereby exposing an API of irrelevant auxiliary functions to the outside world? Yes.

[ilbe]

I think there's a bigger design problem then, e.g. those functions should really be classes. I'm just talking about doing a few 'extract method' refactorings.

[collyw]

I sometimes find that code which doesn't involve lot of nesting is a lot easier to read and comprehend as one long method / function / subroutine than chopping it up into multiple small methods and having to jump around trying to work out what is happening. There is often nothing to be gained by splitting it up in my opinion.

Is that not why some languages are known as scripting languages, because you can read them like a script?

[nthj]

I see what you mean. I'd suggest that longer, more descriptive method names can help here, though. If I'm referring to a method body to understand what it does when reading another block of code, the method probably doesn't have a descriptive enough name.

https://signalvnoise.com/posts/3250-clarity-over-brevity-in-...

[masmullin]

Unless the rewards of crapping-up the code is very high, I find this result highly unlikely.

[romaniv]

Happens all the time with TDD. The worst case scenario is when the code is split up into tiny interfaces that don't represent anything, and the implementing classes have myriad of tiny methods, which also don't represent anything. App logic is effectively composed during run time, and impossible to analyze by looking at the code. Every single method is unit-tested, but their interactions are not (yay, mocking!).