5 ms·
The GOTO topic is an interesting one because Dijkstra inadvertently started a cult around the avoidance of GOTO. Dijkstra never intended this and one of the mai
by jacoblambda 6y ago
The GOTO topic is an interesting one because Dijkstra inadvertently started a cult around the avoidance of GOTO. Dijkstra never intended this and one of the main reasons this occurred was because Dijkstra's original paper "A Case Against the Goto Statement" was editorialised as a letter to the author type article to speed up publication which resulted in the famous title "Goto Statement Considered Harmful".
This is a topic where both him and other prominent figures such as Donald Knuth have since its publication repeatedly argued for moderation in use of the GOTO statement and against the total avoidance of GOTOs.
My go to example for this is that in C and other languages that lack modern comforts such as exceptions(for better or worse) and destructors, GOTOs can largely simplify the handling of clean-up and error recovery code.
Another example is longjmp which is very useful in kernel-space or bare metal programming, and in implementation details for exception handling however outside of those niches, serves no purpose.
GOTO serves a very useful niche but can also make code nigh impossible to follow. Most other structured programming statements have the same threat but we have rules in place to avoid their abuse. The following cases can result in code that is just as problematic:
IF/ELSEIF/ELSE: overly large, overly nested, or mutating variables.
SWITCH/CASE: complicated fall-through.
FOR: mutating counter variables, mutating termination condition.
TRY/CATCH/FINALLY/THROW: exception hell/deep uncaught exceptions.
These control flow mechanisms should definitely be preferred to GOTO in most cases but they can be just as badly abused if you aren't careful. The big difference I find is that people are taught how not to abuse these mechanisms but most material about the proper uses of GOTO is almost taboo because of the cargo cult around avoiding its use.
Sorry if this doesn't really fit into the discussion but it's interesting to me how an initially very tame and rational counter-argument spawned a massive cargo cult.
- marcosdumay 6y ago> but they can be just as badly abused if you aren't careful No, they can't. Old-school goto can create entire new problems in a codebase, that aren't possible to replicate with the structured constructs. That's the entire point of structured programming. Of course, it's possible to use goto well. But eliminating it eliminates the problem.