Optimisation of nested IFs

[Vasily]

Hi All,

How could I optimize this code:
m1 = ...
if (c1) {
m2 = ...
if (c2) {
m3 = ...
if (c3) {
m4 = ...
if (c4) {
m5 = ...
if (c5) {
/*20 more IFs*/
}
else {
/*do something*/
}
}
else {
/*do something*/
}
}
else {
/*do something*/
}
}
else {
/*do something*/
}
}
else {
/*do something*/
}

Is there any nice design pattern make this code smaller.

Thank you

 

[Luke Webber]

Hi All,

How could I optimize this code:
m1 = ...
if (c1) {
m2 = ...
if (c2) {
m3 = ...
if (c3) {
m4 = ...
if (c4) {
m5 = ...
if (c5) {
/*20 more IFs*/
}
else {
/*do something*/
}
}
else {
/*do something*/

[snip]

Instead of c1, c2, c3... and m1, m2, m3..., use a pair of arrays.

Luke

 

[Martin Lansler]

Hi Vasily,

If I intepret your code correctly m<K> will be set if c<K-1> is true. This
could be handled by a list and a for loop such as:

List<Object> ms = new ArrayList<Object>();
List<Boolean> cs = new ArrayList<Boolean>();
//
Random random = new Random();
//
for (int i = 0; i == 0 || cs.get(i - 1); i++) {
ms.add(new Object()); // replace with real m<i>
cs.add(random.nextFloat() > 0.1f); // replace with real c<i>
System.out.println("c" + (i +1) + "=" + cs.get(i));
}


Regards,
Martin.

 

[Eric Sosman]

Hi All,

How could I optimize this code:
m1 = ...
if (c1) {
m2 = ...
if (c2) {
m3 = ...
> [... more of the same, plus some else clauses ...]

If all the m's are of the same type and are set to similar
parameterizable expressions, and if all the c's are also similar
and parameterizable, use a pair of arrays.

If things are less "regular" (the m's are of many different
kinds and assigned from wildly different expressions, the c's
are equally diverse, and the else actions follow no easy pattern),
you might consider using a decision table, sometimes called a
decision tree. They're rather old-hat nowadays, but there used
to be a pretty extensive literature on them: Various ways to set
them up, check them for consistency and completeness, mechanically
combine several small tables into one super-table or decompose a
large one into smaller sequentially-executed tables, and so on.

A lot of the old-time decision table literature had to do with
optimizing the order of tests, taking into account both the expense
of each and its likelihood of yielding true. That's not as big a
concern as it was thirty or forty years ago -- but the ability to
do mechanical checks for "structural integrity" (completeness,
lack of contradiction, and the like) may still be attractive. In
a way, it's in keeping with more modern trends in programming, which
move away from the prescriptive and imperative forms and toward
more declarative problem-oriented forms. (Or claim to, anyhow.)

 

[Vasily]

Thanks! Now I have some ideas how to make that code nicer.

Cheers,
Vasily