Contrast this with textual programming languages, where the reader
may have to scan a large text for labels and compare each label to the GOTO
argument. Interestingly, this provides an argument for the use of line numbers in
code, both on each line and as the GOTO argument: while the semantics of the call
become less clear, the target of the call is easier to ?¬?nd. Even that only helps in
showing where the call goes to; graphical models also show all places that call a
piece of code.
There is also a second reason why GOTO is not as bad in models as in code. While
we can use GOTO to make spaghetti models as well as spaghetti code, in the models
the spaghetti is instantly visible. The instant readability of the control paths warns the
developer early if things are going too far.
A simple sequential ?¬‚ow is itself a kind of GOTO: in a program, the program
counter is set to point to the next statement, just as it is set with a newvalue in aGOTO
command. In a model, the sequential ?¬‚ow is shown by an arrow, and the same arrow
can be used for a GOTO. The use of a GOTO is thus only really of interest in models
when the target is something other than the next object: in other words, when the target
is an object that can already be reached by another path.
Where paths join in this way, a recursive generator will encounter the same
problem as in IF statements above.
Pages:
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537