While I like the object construct and use it in many cases where the values are constant, in this particular case here, it would change the runtime behavior and could lead to unnecessary overhead and bugs. With it, all three functions deadAmount(), separatedAmount(), and retiredAmount() would be called regardless of the actual value of result. Those computations have overhead, could error out, and could have side effects.
Also, in cases where the values are constant and using an object lookup would work, using ?? instead of || for the default value would be even better. If the result for the case is 0, || would trigger because 0 is falsy and normalPayAmount() would be returned, which could be a bug. With ?? this would not happen.
In the original code it was function calls. ?? does not change the behavior in this case, || does if the function returns 0. I'm assuming that the functions return an amount tho, so point taken.
Agreed. Overall this goes back to my point that an object lookup is not the best refactoring here, since there is a risk that it'll change behavior and introduce bugs. Plus it adds unnecessary cognitive complexity.
Btw, I'm a huge fan of using the object lookup pattern when there is a need for it, e.g. when there are many entries or when the entries need to be assembled. In this example tho I think simple if statements are way easier to understand.
Small bonus: this variant would work without the downsides. However, I think it's harder to understand than the approach with guard clauses / early returns:
While I like the object construct and use it in many cases where the values are constant, in this particular case here, it would change the runtime behavior and could lead to unnecessary overhead and bugs. With it, all three functions
deadAmount()
,separatedAmount()
, andretiredAmount()
would be called regardless of the actual value ofresult
. Those computations have overhead, could error out, and could have side effects.Also, in cases where the values are constant and using an object lookup would work, using
??
instead of||
for the default value would be even better. If the result for the case is0
,||
would trigger because0
isfalsy
andnormalPayAmount()
would be returned, which could be a bug. With??
this would not happen.Using ?? or || depends on expected behaviour.
Your argument could be also the another way. So which is better to use depends on expected behavior
In the original code it was function calls.
??
does not change the behavior in this case,||
does if the function returns 0. I'm assuming that the functions return an amount tho, so point taken.if we look to the original code then my assumption isDead, isSeparated & isRetired are booleans.
So in the solution provided as object result needs to be set.
a possible solution could be
Agreed. Overall this goes back to my point that an object lookup is not the best refactoring here, since there is a risk that it'll change behavior and introduce bugs. Plus it adds unnecessary cognitive complexity.
Btw, I'm a huge fan of using the object lookup pattern when there is a need for it, e.g. when there are many entries or when the entries need to be assembled. In this example tho I think simple if statements are way easier to understand.
Agree that if statements with return is easier in this case
Small bonus: this variant would work without the downsides. However, I think it's harder to understand than the approach with guard clauses / early returns: