Flowcharts - a way of drawing GOTOs?

Question

Background: I've inherited a proof-of-concept project which gives the user a drawing canvas on which to construct a flowchart. It then tries to generate some procedural code from the flowchart.

I have serious doubts whether this can ever be truly successful, partly because there are so many bugs, but fundamentally because...

Question: Aren't flowcharts just a way of drawing GOTOs? And therefore isn't it necessarily going to be difficult to generate well-structured procedural code from a flowchart?

Answer 1

Here's my own answer, which I won't accept (at least for a few weeks) because I really want other people's opinions.

Algorithms expressed using flowcharts are more akin to code written using gotos than structured languages such as C#, Pascal or Java.

The flowchart connector can sometimes represent a sequence of statements in code. At other times it can represent part of a structured construct such as īf, while, etc. But it is more generally representative of goto for these reasons:

1. The connector's function is simply to transfer control from one statement to another. This is exactly what goto does.
2. The target of the connector can be any node on the page. Similarly, a goto can target any statement in scope.

This closer similarity between flowcharts and code with gotos can be illustrated by comparing the effects of a small change. Let's look at two versions of a flowchart and see how they can be represented in both structured code and code with gotos.

The only difference between the two versions of the flowchart is in the target of the "registered to vote? No" connector.

Here's Version A as structured code:

REM Version A
decide who to vote for
IF registered to vote THEN
    vote
END IF

Version A's structured code has to be significantly refactored to get Version B:

REM Version B
DO
    decide who to vote for
UNTIL registered to vote
vote

Here's Version A as code with gotos

REM Version A
decide who to vote for
IF registered to vote THEN GOTO VOTE
GOTO FINISH
VOTE:
vote
FINISH:

Version B of the code with gotos is very similar:

REM Version B
DECIDE:
decide who to vote for
IF registered to vote THEN GOTO VOTE
GOTO DECIDE
VOTE:
vote
FINISH:

The changes to the code with gotos are similar to the changes made in the flowchart: change the connector's target, change the goto target. By contrast, the changes required in the structured code bear no resemblance to the changes made to the flowchart: Version A does something if a condition is true whereas Version B does something else until the condition is true.

So the flowchart is more closely represented by code with gotos. There's a closer correspondence between the flowchart components and the goto code components. The flowchart connectors correspond directly to the gotos in the code.

Conclusion

The intent of the algorithm can be changed significantly by making a small change to the flowchart. So you might say that while a flowchart can represent the mechanics of an algorithm, it doesn't do a great job of robustly representing the intent.

This is because the purpose of flowchart connectors is to represent the low-level how, rather than what the algorithm is trying to achieve. By contrast, the constructs in structured code such as if, while, etc. are more about what.

So to answer the question: yes, drawing flowchart connectors is a way of representing gotos.

---

Footnote

As slebetman commented on the question, there are gotos behind the well-structured code we all write in Java, C#, etc., at the machine code level at least. But that's only part of the story. In structured code, the low level goto is always used in a carefully controlled way, and often in association with other artefacts like labels which are not seen in the high level code.