I can imagine multiple scenarios where this could be useful. Simplest is perhaps the coder imagined at the time they could extend the function in later stages.
“You ain’t gonna need it”. It means: Build the thing you need now and don’t try to predict what you’ll need in 3 years. You ain’t gonna need it anyway.
I think it is a balance. Despite having quite functional IDEs now a days, it is still more error prone to change 10 instances of math.random than a single function you define modularly. If you think there is a good chance such an extension might be needed in future or that you might want to change libraries later on, I wouldn’t necessarily call this a bad decision, even if it goes unused.
YAGNI works best when it prevents adding complex unused futures which are error prone and complicates a simpler program logic and flow. In this case you are just encapsulating a function inside another one without any change to program complexity.
It definitely depends on the use case. I could accept this being abstracted out to facilitate mocking, for instance (although I’d recommend mocking at a higher level). But in general this wouldn’t pass review with me unless I get a good explanation for why it’s necessary.
I can imagine multiple scenarios where this could be useful. Simplest is perhaps the coder imagined at the time they could extend the function in later stages.
Then they could add their own function in later stages. YAGNI exists for a reason.
Yagni?
“You ain’t gonna need it”. It means: Build the thing you need now and don’t try to predict what you’ll need in 3 years. You ain’t gonna need it anyway.
I think it is a balance. Despite having quite functional IDEs now a days, it is still more error prone to change 10 instances of math.random than a single function you define modularly. If you think there is a good chance such an extension might be needed in future or that you might want to change libraries later on, I wouldn’t necessarily call this a bad decision, even if it goes unused.
YAGNI works best when it prevents adding complex unused futures which are error prone and complicates a simpler program logic and flow. In this case you are just encapsulating a function inside another one without any change to program complexity.
It definitely depends on the use case. I could accept this being abstracted out to facilitate mocking, for instance (although I’d recommend mocking at a higher level). But in general this wouldn’t pass review with me unless I get a good explanation for why it’s necessary.