The idea that "Goto statement considered harmful" came from an essay by Dijkstra that was published in 1968 during the dawn of computer science.

His basic case was that GOTO was too primitive to have a single easily understood function when seen in code. It tells the machine to arbitrarily move control to a different instruction at a different line of the program but says nothing about why or what's going to be there. Also since you need to physically start reading somewhere else in the code with the context of what's in memory from the previous location in mind it can make programs extremely hard to read and verify, especially in an age before IDEs and debuggers. It allowed for too wide of a gap between the mental model of a static program and a dynamic running process.

He advocated instead for what he called "structured programming" which is really just programming as anyone born after maybe 1964 understands it. Structured programming makes extensive use of this new-fangled idea from the late 50's called "blocks", because someone had to invent the idea of:

if (true thing) {
    doThings();
}
else {
    doOtherThings();
}

at some point.

With blocks that's just the way you write that code with the instructions immediately blocked inside the condition that allows their execution to proceed. With GOTO those lines could be 600 lines away. And without another GOTO to send you back to where you left off, you'll just keep going from wherever you ended up until the program exits or crashes.

GOTO also predates a lot of the looping structures we take for granted in modern programming and while it could be used to implement them, using the actual loops instead carries more meaning and makes your program easier to read, understand, and compile (compilers that translate human-readable source to machine-readable machine code can make certain optimizations in how it feeds instructions into the CPU...as long as it understands what the loop does). So at this point while a lot of the readability issues would be countered by modern tooling, the adoption of more structured ways of writing code and more nuanced looping statements makes goto...kinda pointless.

Its not necessarily, if used correctly. PRoblem is it was arbitrary and prone to abuse; it is (or was, no one uses it anymore) lazy programming in languages higher than assembly.

Usually we want to branch code execution based on some criteria.

IF condition THEN
 do these things
OTHERWISE
 do other things
END IF 
do some necessary cleanup

This way there's a controlled return from the branching. We only have two routes: do these things or the other things. There are no other options or possible routes for execution.

By controlling or containing the execution this way we know that regardless of whether we do these things or other things, we'll ALWAYS wrap up afterward with the necessary cleanup (which might be really important.)

If I throw a random GOTO in there,

IF condition THEN
 do these things
OTHERWISE
 do other things
 GOTO XANADU
END IF 
do some necessary cleanup

#XANADU 
 do some unrelated stuff
 get lost

unless I explicitly end that goto with another GOTO that returns me to where I left off, I might never return. We'll never do the necessary cleanup for example.

Using GOTOs allowed you to jump ANYwhere. I could jump into the middle of other branches I could jump out of loops willy nilly; yeah, this is still allowed with break statements but at least the break statement just exits the loop, a GOTO could warp you anywhere. So very powerful... but it also lets programmers be lazy. Code getting too complicated? Can't find a way to structure it properly so error and failure cases return you to someplace sane? Meh, bash a GOTO in there. Its like a magic code ticket that takes you to where you want to go with no (and by that I mean all the) consequences (unallocaed memory, initialized/uninitialized variables, who knows).

A GOTO is like a magic airline ticket that takes you anywhere in the world. Except when you get there you may not have any luggage. Or both feet.

First you have to understand how it was originally used, then understand what replaced it, then you can understand why it's not used anymore.

The ability to skip ahead or skip back to a different line of code lets you do a great many things. It's generic and open-ended what it can do. When you create a way to do it conditionally where it won't always execute the goto then it allows for all the standard flows we use today.

An If-block is really just "If this condition isn't true then GOTO the spot just past this block so you skip over it."

An unconditional loop is really just "GOTO a previous line up above so you start executing all this stuff again. When you get back down to this line, GOTO the top again. Repeat."

A conditional loop is really just "IF the thing we're checking for to end the loop isn't true, then GOTO a previous line and run that stuff again."

It's versatile. It can form just about any pattern.

So what's the problem? Well that versatility IS the problem. To understand why a programmer put a GOTO there, to understand what they were trying to do, you have to analyze a lot more lines of code to see what the pattern was. Because a GOTO could really be for a wide variety of purposes. It might be part of an IF. It might be part of a WHILE (thing is true) loop. It might be part of an UNTIL (thing is false) loop. It might be part of a counting loop (FOR loop). It might be to just jump over to a subroutine and return from it.

It's not visually obvious from just looking at it what it's for. You have to trace the code line by line before you can see the big zoomed-out picture of the layout.

It also allowed unique flow patterns that don't fit into one of the commonly known patterns. A clever programmer could have been using it to do something unique that only makes sense in their own mind and doesn't make sense to anyone else.

So, essentially, it can make the program hard to understand, which then means programmers make mistakes when editing it.

The fix was to find all the common things people were using GOTO to do, and create special keywords for those patterns and replace the use of GOTO with those new terms. So you can still do all the same stuff, but in a more descriptive way that actually says what you're doing. You don't have to guess "Which of the 8 or 9 different reasons for using a GOTO might this one be?" when it uses a word like WHILE or FOR or IF that actually tells you which one it is.

But the interesting thing is... under the hood, it's still really all GOTO. At the lower machine language level, you have the various JUMP instructions, which are exactly what a "GOTO" would have compiled into, and as it turns out, is also what the newer words like WHILE and FOR and IF also still compile into.

Under the hood, it's still all GOTO. But now it has more descriptive ways to summarize those GOTOs into human-readable structures.

Mostly just because they make a mess out of the flow of the program. Modern languages have tools you can use to perform complex logic with a syntax that doesn't seemingly arbitrarily hop all over the code to get things done.

GOTOs were useful in the early neolithic era when Grog first invented COBOL and the concept of a "loop" was novel, but nowadays there are better options. If you find yourself in need of using one, chances are that whatever structure you have in mind can be represented in a way which doesn't need a GOTO.

[removed]

It's what you tell beginners to keep them from making too much of an unmaintainable spaghetti mess, which is what people will generally end up with if they think of it as a general-use tool in their toolbox, instead of merely for a few specific narrow situations. But it's not quite as absolute as it's usually presented.

The Linux kernel uses gotos in a structured way that's helpful. (If you're using C++, you should probably instead use RAII to do what they're doing, but in C careful use of goto can be worthwhile to get a similar effect.)

Some would claim breaking out of multiple levels of nested loops also is a good use case, and produces code that's easier to read than trying to chain breaks through multiple loops. Common wisdom is you're better off putting your loops in a function and using 'return' when you need this, but it's a debatable point when goto is in the language.

It becomes very hard to manage the order of execution of parts of your program. Normally with a function, you call it and you return. With a "goto" you just go forward (and no return). It is prone to result in so called spaghetti code which is often buggy (and it is hard to read -> hard to maintain).

Note that the construct is not inherently evil. It is just the structure of the code that is undesired.

GOTO is considered an anti-pattern because it introduces non-linear control flow into a computer program - computer programs are generally written with linear control flow.

GOTO allows you to jump to any location in your program without any respect for how you got there - it's basically one-way teleportation.

Being able to teleport anywhere without respect for the structure of a given computer program allows you to do virtually anything regardless of how you got there, and, this leads to people doing a lot of weird things just because they can.

This is really the only reason why its use is considered an anti-pattern, and there's nothing wrong with using GOTO if you really know what you're doing.

Generally speaking you should stick with established well-known control flow semantics to make your program as easy to read as you can.

It's actually GREAT practice! How else can you write this little gem in beginners all-purpose symbolic instruction code: 10 Print"Hello lovely!" 20 Goto10

It's not a bad practice because it's impossible to use it in a way that avoids problems; it's considered bad practice because it's possible to use it in a way that causes problems.

This is often the case in programming. You'll find that people will argue that such-and-such is okay because "if you just use it correctly, there's no problem." But correct usage isn't always straightforward, and the less straightforward it is, the more problems there are.

Ideally, a perfect programming language would provide only constructs that make it impossible to represent unintended things. In fact, this perfect programming language actually exists in theory! It would be a programming language which requires formal proofs of all possible functionality. This sounds absurd, but in reality, even though it's impossible, it's less impossible than it at first seems because you can do things like method guards and early escape returns, which reduce the space of test cases from virtually infinite to merely unmanageable and totally unrealistic (for real systems, not toys).

Example time. Say that I want to write a method that can multiply integers from 1 to 10. A first year student in coding 101 will write something like:

/** Return product of a and b. */
int mult(int a, int b) { return a*b; }

…and feel proud that they not only addressed the requirement, but produced something much more general purpose that will also work for any two integers.

How silly and naive. What they failed to account for is that this doesn't actually work for any two inputs, and if you were to exhaustively test every single combination of 32-bit inputs, you'd find a large number of them that result in overflow conditions (like a = b = max int). But that's okay, it still does the thing it's supposed to for the expected inputs, so what's the problem? The problem is that since you specified a looser contract for this method than was required, you have not addressed just the requirement but the looser contract you chose to support (because of Hyrum's law).

If you actually restricted the contract to just the requirement:

/** Return product of a and b if both are between 1 and 10 (inclusive). */
int mult1to10(int a, int b) {
  if (a > 0 && a <=10 && b > 0 && b <= 10) { return a*b; }
  // do some crazy ish
}

In design-by-contract rules, if you don't specify in the contract what a method does, then it is unspecified, meaning that you can literally do anything and still be in compliance. You could go into an infinite loop. Call System.exit(9). Whatever.

Because everything is allowed when a or b are outside the specified bounds, it's super easy to prove that this method formally complies with its contract. The space of the inputs is so small you can even practically write a set of exhaustive tests, and you could also formally prove using lambda calculus or whatever based on the code as written that it does exactly what it says it does.

What does this have to do with your question? What I'm doing here is introducing these notions of formal proof and exhaustive testing not because it's practical, but rather to connect the idea of "covering the entire space of possible inputs" with the ability to reason about code. In mathematics we have this notion of continuity, whereby we say a function is continuous if the outputs transition smoothly from one value to another if the inputs transition smoothly from one value to another. Now just because these transitions are smooth doesn't mean that outputs don't move around in an absolutely wild and unpredictable way, but for a lot of functions you can make strong statements that outputs definitely don't do that. You could have a function where you prove that it it's monotonically increasing, and the increase in the output is proportional to the increase in the input (y = 5x, for instance), so you'll never see weird or erratic behavior in the output for a steady increase in the input.

See where I'm going with this? If you write methods that behave like simple mathematical functions that are easy to reason about because they are constrained in particular ways, then we don't need to exhaustively test every possible combination of inputs. We can say, for example, that if you put in a 1 and get a 5, and you put in a 100 and get a 500, that's good enough to assume if we put in something between 1 and 100 we'll get something between 5 and 500. But you can only say this if your function behaves like y = 5x and isn't trying to tell you angles of Foucault's pendulum or some chaotic process.

This was the problem with the simple code we wrote in the first example above. Given a simple requirement, we decided to tackle the entire class of inputs and wound up with an output that has significant areas of discontinuity (int overflow). We could solve that problem by returning a long, and now we can say that, hey, it's now a simple method we can reason about. Problem solved! Right? Right???

Not really. Clients ruin everything.

The problem is still not solved if what clients really need is an int. Remember, we're writing this method according to some contract not just to occupy our time; presumably we have callers we are trying to support. If we're going to change the contract by returning a long instead of an int, we had better be darn sure that change does not diminish the utility of the contract!

If it does, and clients actually need an int, then what they're going to do is cast that result to an int. If they screw this up by not checking for overflow, then we have not really solved a problem, we just relocated it. Even if they don't screw it up and they do all the correct bounds checking, we are putting extra work on each and every client that we could centralize in one place … and that's the whole point of doing this work in the first place, right? I mean ,couldn't callers just do the multiplication themselves too? Why ever provide any API that does anything?

So there's no escape. As a provider of an API, your job is to provide a contract that meets the need of the caller, and do it as correctly as possible. That's a good API.

But as we see from the above two examples, when we did a seemingly innocuous thing, we introduced unexpected behaviors into our implementation. It's really, really easy to do because it's really, really hard to write code that's really, really easy to reason about.

And, finally, at long last, we go way back up to the top of this post and reread what I wrote there: Good practices are good not because they make it possible to do the right thing, but because they make it impossible to do the wrong thing. Ideally. In practice, the best you can do is make it harder to do bad things, and easier to do right things.

And that's why goto is bad. There is nothing you can do with a goto that you can't also do with other programming constructs minus the big ol' footgun that goto hands you because these alternatives all come with additional restrictions on how control flow is handled that make them easier to reason about.

I'll add a little bit of philosophy and theory to this:

The general trend in the development of paradigms, rules and methodologies has been to restrict the programmer from doing certain things. goto lets you arbitrarily move to a different place in the code. This can be made less arbitrary by forcing the programmers to use functions and loops.

Similarly, encapsulating variables is a restriction. It restricts easy access to the variables from outside the class.

Type safety is a restriction. It forces assignment and other operators to require explicit casting for variables of different types.

So on, so on.

Without restrictions, the programmer could do anything at any time and it would be extremely difficult to read such code. When you restrict things, you force the code from different programmers to be more easily understandable and you (hopefully) decrease the amount of bugs in the code.

Sometimes you create a restriction that makes it hard to express some things in a clean way. For example, in C, goto still has a place in error checks and in ensuring that an error causes a function to release the resources it initialized at the start of the function. In more modern languages, there really isn't any reason to ever use goto, since the languages offer other more powerful (and more restricted!) constructs for dealing with the issues that goto is used for in C.

It's easier to understand something when all the pieces are next to each other in a straight line. You tell the computer to do this, then this, then all of these, then frobnicate the widgets, then pass the salt. When you see a loop, you know the computer is going to repeat what's in the loop a certain number of times, then do the stuff after the loop.

"goto" lets you tangle up the pieces as much as you like. The problem is not the word "goto" itself, but it is the fact that if you didn't create a tangled mess then you'd be able to write it without the word "goto". An otherwise straightforward program with one or two "goto"s is often still understandable, but when you have many of them, it can be hard to understand exactly what the program is doing, e.g. you might not even be able to work out how many times a certain line of code gets run.

Note that when Edgar Dijkstra wrote his famous letter "Go To Statement Considered Harmful" in 1968, structured programming with instructions like "if" and "while" were somewhat new and people weren't using them as much as they could have.

Ironically, many programmers write the exact same kind of mess with classes and methods, and think it's good because there's not a single "goto".

There are usually easier to read options that structure the code better. The most common valid use for it is jumping out of nested loops.

[removed]

The flow of the program is determined by your imperative or declarative programming. You do things once by once or declare what would happen if an event occurs.

Goto messes up this flow and makes the code way harder to track. It gives programmers too much freedom, they need to be constrainted by shackles or eveything gonna be catastrophic once day.

[removed]

Other constructs return control to the thing that called them, keeping the line of processing much much clearer.

The alternative is what we call "spaghetti code", where determining the true path through the code is damned near impossible...like trying to follow a strand of spaghetti through an entire bowl of it.

Structured programming code can generally be read from any position, in either direction: If you find a train car on a track, you can check what it went through before by following the track towards where it came from.

A Goto works closer to a Starfleet transporter: When you find a train car on the track, it might just have teleported in there from wherever. If there are traces of an ambush a mile up the track, you have no idea if that train car went through it.

Goto is a tool which often allows you to do something easily instead of doing it right.

For example, maybe Goto would make your program work now, but it will make it harder to resolve bugs and if there are later changes they could be much harder to implement.

[removed]

I used GOTO like candy in the early 80's with Microsoft BASIC! But otherwise, I've been coding professionally since 1996 and have used GOTO exactly once and that was last year actually, to jump to some error handling code in a particularly dense and multi-faceted set of conditionals. It seemed like the cleanest way to handle things, and it was within the same function of course so pretty reasonable.

Control structures like if/else statements, while loops, and for loops place the code that is executed when the condition is true or false in predictable places, and more importantly, (unless there was an early return or a thrown exception), the control flow always returns to the line after the end of the (for example if/else) block when the conditional part is done. Goto has no such guarantees: it could send you to some arbitrary line earlier or later in the code and the only way to figure out if you ever come back is to go see if some other goto sends you back. Using gotos also means that there could be parts of your code that don't really make sense unless you know what gotos send you there.

As a result, gotos can make your code very hard to understand by inspection, and it also means that it's easier to make mistakes when writing code with gotos. That's not to say that it would be impossible to write readable code with gotos, but if you put all your conditional logic in predictable patterns, you're probably structuring it the same way you would using if or while statements anyway.

[removed]

In the old times there was only goto. And it led to really bad code. Then there was a time where using goto was considered extremely bad programming.

I've seen a lot of places where gotos make sense. Mostly (if not always) in error handling where gotos can actually clean up convoluted code when you can't use exceptions for some reason.

The issue is that "goto" plops you somewhere in the program, but with little to no way back.

Programming practice likes consistency, and linear flow. Every line is an instruction, and should be followed in sequence.

Even if I have to say, call a method from somewhere else in the code, I'm still sitting in the same place. I can leave where I am, go do whatever, then come back and continue where I left off. Clean.

"Goto" though? I could've jumped 5 lines ahead, or 269, and I have no way back. It's obscenely reckless in large programs, making them an absolute pain to edit, and it's just lazy in smaller programs.

My probably out of date understanding is that goto ignores stack management. Stack allocated in the current context would remain allocated wherever the goto ends up. Done repeatedly this will lead to a stack overflow.

[removed]

GOTO is one of a handful of really fundamental, core concepts in programming, you basically can’t achieve anything useful without it. The flip side to that is that, because you need GOTO for everything, you need to read a lot of the surrounding code to understand what, exactly, you’re trying to achieve.

As it turns out, there’s a small handful of uses (if/else, while, for, try/catch, function calls) that completely dominate compared to everything else. Instead of a goto that can mean anything, you can use one of those language constructs instead and say exactly what you mean (this is also why most languages are slowly adopting for x in list, because it’s the most common usage pattern for for loops). This is easier to read, it’s less error prone (because the compiler/interpreter can handle all the setup and cleanup chores for you).

People do forget that there is a long tail of legitimate use cases for goto, though, which is a bit of a shame.

[removed]

I remember GOTO in combination with line numbers made maintaining or adding new features in Basic a nightmare. It's hard to tell which lines are being jumped into, meaning that by changing a line of code, you can invertedly break the program flow if you are not paying close attention to any gotos pointing at it.
To avoid this, you avoid changing any existing code that works by jumping around it. All this jumping around then results in a difficult to follow flow.

Using a bad but simple example of spaghetti code:

10 let a = 10

20 let b = "spaghetti"

30 print b

40 let b = "pasta"

50 let a = a + 10

60 if a < 60 then goto a

70 print "code!"

While clever, "spaghetti" shouldn't be printed twice. The right thing to do is rewrite this entire block of code, but you can't really do that if this is part of a larger program with other parts jumping into it as you could risk breaking other parts of your program.
So instead, using the above method of coding around problems, a bug fix could end up looking like this:

10 let a = 10

20 let b = "spaghetti"

30 goto 50

40 let b = "pasta"

50 print b

55 let a = a + 10

60 if a = 20 then goto 40

70 print "code!"

Not very pretty at all.

It's the difference between teleporting to your destination and actually walking to your destination. Both gets you there but by walking you have an idea of how you got there.

Literally because one guy said so and others latched onto it. It's like he never wrote in ML/ASM at the time. Nothing wrong with goto, its not bad. There are bad usages of course. I look at the "goto bad" folks as dumb asses following an unvetted religious assertion, and I'd love to see them program in ML. Their code would be bloated shitware.

What is more important is to document, especially strings, and complex functions. I found an old phreak tool/code hacker I wrote in 1988 on a the scene database. The gotos are not what makes it hard to follow. It's my various string handlers and no documentation of my variables.

Structured programming is a great idea; but not necessary for readable or useful code. Further, this religious bullshit killed many of the 'i program for myself' coders by making simple things more complex. Good programming means understanding the tools you have and implementing them to serve your desired ends. Goto allows for smaller code in certain situations, along with easier to read code in others. As line numbers were replaced with labels (like in qb4.5) readability options also increased.

10 print "i love goto! ";
20 goto 10

or

home
print "i still love goto! ";
goto home

TLDR: some jackass who didn't consider ML said something stupid about spaghetti code and readability and people took it as religious fact.

[removed]

There's been some great explanations, so I'll add something else.

Programming languages can also be ranked according to how close they are to the hardware. Assembly code is at a pretty low level where it directly gets translated to machine code. Assembly code contains e.g. jump instructions which is a more basic version of a goto statement. Anybody that has coded like this knows it can get pretty complicated quickly — as mentioned by others. That's what you have, so you need to use it, but you can build higher level abstractions where you don't directly need to deal with it (higher level languages, function calls, etc.).

Now, in many old games (like running on DOS), a popular hack was to disassemble the code and then insert jump statements to get around password or other checks. This is one place where it was useful, albeit perhaps illegal in some cases. This is also potentially useful for code where you don't have the source to recompile it, but need to fix something (I don't have an example at hand, but it has happened).

Lastly, it also gets used in a form of hacking known as ROP (return oreinted programming).

Dedicated branches are unnecessary. You don't create a turn in the road for no reason. It will just cause the driver to lose their way. Someone that has to fix the code will often lose their way of there are unnecessary turns in the road.

Often, people rely on goto and get lazy when coding.

Goto is fine when there is no other option and you need to do some spaghetti.

I use goto, but only sparingly. I use them to get out of complex nested loops or switch/cases and jump either to the end or to the beginning of a function where I would have a maintenance routine to clean up before leaving the function or to reinitialize and restart the nested loop.

If you start using gotos where they're not needed at all, you're just asking for trouble down the road.

I'm pretty sure if the ancient Minoans had enjoyed the ELI5 subreddit, Linear A would have been cracked long ago.

Excellent top comments so far.

As a side note: goto is often used in code golfing (the act of trying to write a piece of code in as small amount of characters as possible) because well, it's shorter than writing 'while(1)' for example.

In the case of PICO-8 (and by extension Lua) it's the difference between "::x:: do stuff goto x" and" while 1 do do stuff end" which is 2 characters longer