7 ms·
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
by route66 13y ago
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 13y agoI 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 13y agoI 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 13y agoI 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-variable-and-method-names https://signalvnoise.com/posts/3250-clarity-over-brevity-in-...
- masmullin 13y agoUnless the rewards of crapping-up the code is very high, I find this result highly unlikely.
- romaniv 13y agoHappens 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!).