Stop teaching students to avoid goto so that it takes hold again, leading to bad code all over the place, so that we can empirically prove that it's a bad idea? How about we just don't do that and avoid the problem to begin with.

Unrestrained use of goto was demonstrated to be a bad idea decades ago, that's why Dijkstra recommended against it in 1968.

The point is that people do not generally use goto in these harmful ways because they've been warned not to. That's what skews the study in the summary. You're going to have a hard time finding that empirical evidence of how goto can lead to bad code, because one of the first things coders are taught in today's programming courses is, "Do not use goto." Meaning that the inexperienced coders who would be having these problems are avoiding the problem by not using goto. Those who are using goto are those who know the risks and how to mitigate them.

So, in the absence of conclusive data either way, I can only argue from my experience. I'm a programmer who has used both goto and more tightly-controlled flow control, and in my experience goto is not a good option for the vast majority of cases (particularly for inexperienced coders).

And why do you think this is bad practice?

Good coders can definitely mitigate the risk of goto statements. However, goto makes it easier to really screw things up if you don't 100% know what you're doing, or if you make a mistake.

Not sure what you're getting at with compilers. Once you translate a C program to assembler/machine code, most of your loops, switches, breaks, etc. all become effectively the same as goto. The problem with goto has nothing to do with the compiler, it has to do with the human being trying to read, write, and debug the code before it goes through the compiler, and with catching errors at compile-time with sane control flow, whereas with goto it will make it through the compiler and become a runtime error.

You complain about the giant if/for nests, but those huge nests will almost always become worse if you start throwing gotos in there.

Yes, goto is a tool like anything else. But it is not a tool for the common case or the common coder. Most of the time, if you're asking yourself, "should I use goto here or something else?" the answer is the something else.

If you think modern code is horrible spaghetti (I disagree, for the record), bear in mind that it would be considerably worse with indiscriminate use of goto.

Sure, code has complex code flow. When code is designed to solve complex problems, it's going to be complex. Complexity is okay. The key is being able to make complex code clear, readable, and less error-prone. Goto is less clear and readable because it's not obvious what a goto statement is meant to do. When you see a while loop, or a break statement, or a function call, you can get an idea of what it's doing just by the nature of what statement is being used. Goto can be used to cover any of those cases, so it's more difficult to follow. Because of this, it's also easier to make a difficult-to-debug mistake!

99% of the time, when you could use a goto statement in code, there is another, better way of doing the same thing. An expert coder will be able to effectively use it in a way that limits the risk, but for a novice or intermediate coder, or even many experienced ones, it is much easier to muck everything up using goto vs. using other control flow tools.

Nah, I think it's clear that Microsoft is not counting in decimal like the rest of us. Sure, they start with 1, 2, 3 like you'd expect, but then after that it's 3.1, 3.11, 95, 98, 2000, XP, Vista, 7, 8, 10, 365. The next version will be something like 13.111.Xylophone. This is not Base 10. This is Base Bob.

I think I just pulled my hamstering while running away from this conversation.