7 ms·
> The point of passing boolean params instead of named functions is that most of the time there is shared code between the two paths and not literally all the c
by mdpopescu 10y ago
> The point of passing boolean params instead of named functions is that most of the time there is shared code between the two paths and not literally all the code is enclosed in either the if or the else block
If you have this
method(bool arg)
{
// block A
if (arg)
{
// block B1
}
else
{
// block B2
}
// block C
}
you can replace it with
method1()
{
A();
B1();
C();
}
method2()
{
A();
B2();
C();
}
where A(), B1(), B2() and C() are new methods that contain the previous blocks. This makes the code clearer, IMO.
- Kristine1975 10y ago>This makes the code clearer, IMO. Depends on how much state you need to pass between A, B1, B2 and C.
- majewsky 10y agoIt also depends on the semantic value of A, B1, B2 and C. If you cannot express them as senseful steps of your overall algorithm, then you are bound to end up with very confusing method names like calculateFooAndCreateBarAndAlsoInitializeBaz, or (even worse) prepareForFoo. EDIT: By the way, an anecdote. Years ago, I was working with an offshore developer who was producing huge scripts without any modularization whatsoever. In particular, we told him that a certain 2000-line script needed to be modularized, so he should break out steps into functions etc. He produced a new version containing two functions of 1000 lines each. The first function would prepare everything, then tail-call the second function with 27 arguments, most of them large intermediate data structures.
- Kristine1975 10y agoCould have been worse: He could have made 1000 functions two lines each.
- jasonlotito 10y agoIf the amount of state you need to pass is that significant, that is another code smell that needs its own resolution.