3 ms·

Agreed, although I think the example isn't too bad. I often see such "helper methods" - usually in a class called "utils" or "misc" - when (novice) programmers

Agreed, although I think the example isn't too bad. I often see such "helper methods" - usually in a class called "utils" or "misc" - when (novice) programmers "try to plan ahead": how should I write this so it can be re-used? But KISS is remains a good principle. Predicting the future is hard. If in doubt, don't put in the extra indirection/abstraction. If/when the next person needs that functionality, they can refactor it - and the simpler/more straightforward the code, the easier it is to refactor! When the logic is already split over multiple methods, refactoring in a different direction becomes harder. Often, it's enough to verify there's only one caller, and then stuff it back into one method before refactoring. Still, more annoying than if they hadn't of overthought it.

usrusr 7y ago
In my mind I contrast "keep it simple" with "make it simple". Successful "make it simple" is better than "keep it simple", which in turn is much better than failed "make it simple". Every attempt at "make it simple" is a wager. Regarding the one-caller method, beloved by followers of maximum method length ideology, scorned by enemies of excessive indirection, I think we lost a very useful tool when the "structured programming" of Pascal, which prominently featured nested functions as an organisation principle disappeared. It got steamrolled by OOP name scoping (which tends to be too big for this use case) from the top while the archaic "if it exists, it is accessible" of C firmly held the lower levels. The current trend of retrofitting functional features is technically getting us back what we lost, but the use of nested functions as a simple organisational tool is still far from idiomatic. E.g. in Java>=8, when you see a lambda assigned inside a method you expect something clever functional to follow, not a simple "I put this block of code in a box to give it a name, but it won't be meaningful outside this method".
- JamesBarney 7y ago
  C# has local functions which I've been making a lot of use for this exact purpose.
- blt 7y ago
  I really like this pattern, but unfortunately some people consider it confusing when the closure capture is not explicit. C++ lambdas are nice in that regard.
- guitarbill 7y ago
  agree, like you said it's probably a teaching thing. in e.g. python, javascript, and others, nested functions are available and first-class citizens. (okay, those languages have other issues) really, there isn't a substitute for experience, but we can try. and again, the devs who do this mean well, they just don't know better yet. that's still better than apathy
UglyToad 7y ago
The other thing you see is extraction of logic applied, particularly to business logic, prior to the actual logic being clear. So a developer will notice two very similar bits of code and maybe include some kind of parameter to a method or even worse, build some kind of abstraction (inheritance shudder) then as the project evolves it turns out there are actually very different business requirements for each case and you're stuck in a bit of a mess. As you say there's a cost to optimization, the wrong abstraction is far more painful than no abstraction. This quote from another blog post the other day is relevant I think: "Future thinking is future trashing When developers try to solve a problem, they sometimes try to find a way that will solve all the problems, including the ones that may appear in the future. But here is the thing: The problems from the future will never come and you'll end up either having to maintain a huge behemoth of code that will never be fully used or you'll end up rewriting the whole thing 'cause there is a shitton of unused stuff. Solve the problem you have right now. Then solve the next one. And the next one. At one point, you'll realize there is a pattern emerging from those solutions and then you'll find your "solve everything"." These are all just re-statements of KISS and YAGNI but it's definitely the most important principle.

usrusr 7y ago

In my mind I contrast "keep it simple" with "make it simple". Successful "make it simple" is better than "keep it simple", which in turn is much better than failed "make it simple". Every attempt at "make it simple" is a wager. Regarding the one-caller method, beloved by followers of maximum method length ideology, scorned by enemies of excessive indirection, I think we lost a very useful tool when the "structured programming" of Pascal, which prominently featured nested functions as an organisation principle disappeared. It got steamrolled by OOP name scoping (which tends to be too big for this use case) from the top while the archaic "if it exists, it is accessible" of C firmly held the lower levels. The current trend of retrofitting functional features is technically getting us back what we lost, but the use of nested functions as a simple organisational tool is still far from idiomatic. E.g. in Java>=8, when you see a lambda assigned inside a method you expect something clever functional to follow, not a simple "I put this block of code in a box to give it a name, but it won't be meaningful outside this method".

JamesBarney 7y ago
C# has local functions which I've been making a lot of use for this exact purpose.
blt 7y ago
I really like this pattern, but unfortunately some people consider it confusing when the closure capture is not explicit. C++ lambdas are nice in that regard.
guitarbill 7y ago
agree, like you said it's probably a teaching thing. in e.g. python, javascript, and others, nested functions are available and first-class citizens. (okay, those languages have other issues) really, there isn't a substitute for experience, but we can try. and again, the devs who do this mean well, they just don't know better yet. that's still better than apathy

UglyToad 7y ago

The other thing you see is extraction of logic applied, particularly to business logic, prior to the actual logic being clear. So a developer will notice two very similar bits of code and maybe include some kind of parameter to a method or even worse, build some kind of abstraction (inheritance shudder) then as the project evolves it turns out there are actually very different business requirements for each case and you're stuck in a bit of a mess. As you say there's a cost to optimization, the wrong abstraction is far more painful than no abstraction. This quote from another blog post the other day is relevant I think: "Future thinking is future trashing When developers try to solve a problem, they sometimes try to find a way that will solve all the problems, including the ones that may appear in the future. But here is the thing: The problems from the future will never come and you'll end up either having to maintain a huge behemoth of code that will never be fully used or you'll end up rewriting the whole thing 'cause there is a shitton of unused stuff. Solve the problem you have right now. Then solve the next one. And the next one. At one point, you'll realize there is a pattern emerging from those solutions and then you'll find your "solve everything"." These are all just re-statements of KISS and YAGNI but it's definitely the most important principle.