good ... should be clear to a human reader. Inappropriate use of goto's can go against this
I pretty much agree a 'goto' is a special tool for a special case. Could it be that source code has inherently one-dimensional aspects to them (the flow of the program counter / instruction pointer through the code, the way the call stack works), and a goto works against this mind set by allowing unstructured jumps?
I've never seen anybody say that flowcharts are bad, as they allow you to draw arrows across logical boundaries, maybe they need a rule that you should never 'cross the streams'?
Neither in formal state transition diagrams, where you can jump between arbitrary states however you see fit. When you convert a FSM to code you basically end up with spaghetti.
I definitely remember the "no goto" rule being around in the early 80s in the time of structured BASICs, PASCAL and COBOL... Maybe a lot of it is hangover from old languages where your GOTOs used the line number as the target for jump, rather than a label. Those days were really nasty - if you renumbered code you could shoot yourself in the foot sooooo badly. These days the destination for a goto is has limited scope, and so at least it has a bit of structure to it.
One C coding standards I had to follow in the 90s recommended this construct for processing errors:
void some_func(void)
{
do {
if( ! something_that_might_error() ) /* e.g. malloc or fopen() */
break;
if( ! something_else_that_might_error() )
break;
<do the real work>
return 1; /* Success */
} while(0);
<error handling code>
return 0; /* Failure */
}
It was a poor man's way of exception handling, or abusing C to give 'goto' like functionality without actually using the word.
Anyhow - just idle musings rather than me saying anything of any value.