RPA Graphical Code Representation - Fine Differences

[StefanSchnell]

A few month ago I published a post about the Nassi-Shneiderman diagrams. Recently I had an interesting analysis that showed me very drastically the fine differences of the different approaches of graphical representation of code. Besides the Nassi-Shneiderman diagrams there are e.g. the DIN 66001 graphical symbols for program flowcharts. In this post I show that complexity can be represented differently and even “hidden” via the chosen approach of graphical representation of code.

The starting point was a concatenation of seven checks that were implemented via If queries.

This looks simple and understandable. However, in a different graphical representation, a different perspective arises.

When we look at the resulting code, we see the complexity even more clearly, among other things, the high nesting depth of eight levels.

// Generated by Structorizer 3.32-06 

using System;

public class ConditionTest
{

  public static void Main(string[] args)
  {

    ??? Element;

    bool[] CollectionOfConditions = new bool[]{};
    bool Condition1 = true;
    bool Condition2 = true;
    bool Condition3 = true;
    bool Condition4 = true;
    bool Condition5 = true;
    bool Condition6 = true;
    bool Condition7 = true;

    foreach (@boolean Element in new @boolean[]{CollectionOfConditions}) {
      if (Condition1) {
        if (Condition2) {
          if (Condition3) {
            if (Condition4) {
              if (Condition5) {
                if (Condition6) {
                  if (Condition7) {
                    Do something;
                  } else {
                    continue;
                  }
                } else {
                  continue;
                }
              } else {
                continue;
              }
            } else {
              continue;
            }
          } else {
            continue;
          }
        } else {
          continue;
        }
      } else {
        continue;
      }
    }
  }

}

With a tiny trick we can reduce the complexity dramatically …

… with the negation of the conditional query. The nesting depth is reduced to two levels.

// Generated by Structorizer 3.32-06 

using System;

public class ConditionTestNot
{

  public static void Main(string[] args) {

    ??? Element;

    bool[] CollectionOfConditions = new bool[]{};
    bool Condition1 = false;
    bool Condition2 = false;
    bool Condition3 = false;
    bool Condition4 = false;
    bool Condition5 = false;
    bool Condition6 = false;
    bool Condition7 = true;

    foreach (@boolean Element in new @boolean[]{CollectionOfConditions}) {
      if (!Condition1) {
        continue;
      }
      if (!Condition2) {
        continue;
      }
      if (!Condition3) {
        continue;
      }
      if (!Condition4) {
        continue;
      }
      if (!Condition5) {
        continue;
      }
      if (!Condition6) {
        continue;
      }
      if (Condition7) {
        Do something;
      } else {
        continue;
      }
    }
  }

}

This looks much smarter, doesn’t it.

Very interesting now is the display in the flowchart, it hardly changes.

With the flowchart diagram you have to look very closely to recognize this form of complexity and unfavorable design, which also entails more complex code generation. The Nassi-Shneiderman diagram is the better approach in this case.