Many neophyte programmers believe there is something unclean about using a visible GOTO, and no "good" programmer would ever do so. Since most of these true believers don't know the origin of their superstition, here is a short bit of computer history.
It all started in 1965 when Professor Dijkstra delivered a paper making a plea for clarity in program source code. Most of what he had to say is long forgotten, but a few statements had a profound effect on computer science as it is taught today. Dijkstra told how "two programming department managers... [had] communicated to me, independently... that the quality of their programmers was inversely proportional to the density of goto statements in their programs. This [was] an incentive to do away with the goto statement."
So he reprogrammed some problems "in modified versions of ALGOL 60 in which the goto statement was abolished and the for statement — being pompous and over-elaborate — was replaced by a primitive repetition clause... In all cases tried... the program without the goto statements turned out to be shorter and more lucid."
While not specifically stated, Dijkstra's conjecture was obvious. If he could always produce better ("more lucid") programs by using a GOTO substitute (the "primitive repetition clause") instead of the naked GOTO, poor programmers would become better programmers if only the GOTO were abolished from the programming languages. The "goto is harmful" school of computer science was born.
Nobody in this school seems to have noticed all the programs for which the naked GOTO is the best programming construct, both in terms of program clarity and in performance. One major class of these consists of programs characterized by being easily described with a state diagram where at least one state has two or more successor states, at least one of which also has two or more successor states. Compiler parsers, although sometimes written in strange languages that do not have a real GOTO, are members of this class.
It should have been obvious to everyone that the "goto is harmful" argument is based on a fallacy. Removing a useful, if sometimes misused, tool from the programmers' toolbox cannot possibly make better programmers out of poor programmers. The result of the nonsense is a generation of programmers not skilled enough to know how to use a GOTO. Instead, this generation believes that any program with no visible GOTO is a sign of a good programmer, and so clutters up its programs with a rash of useless, specialized GOTO substitutes.