24 Replies - 4152 Views - Last Post: 03 March 2010 - 03:14 PM

The demerits of goto

Posted 14 October 2009 - 07:26 PM

In normal C++ coding; there is no reason to use the goto statement. Compilers are very good at optimizing code; the structural information provided by using functions, looping structures and exceptions help others know exactly why jump statements are being performed and allow a quicker learning value to come from it.

I was wondering when explaining why goto statments should be avoided; what explainations others use.

Re: The demerits of goto

Posted 14 October 2009 - 09:54 PM

Quote

They aren't ever useful in the world of module programming.

I would not say that was true -- you should never speak in absolutes!

Goto has its uses. For example in recent months I have seen it pop-up in a few meta-programs where I myself could not think of anyway to achieve the end result without them. They can be useful when using inline assembly routines. You will also see it in maintenance code -- This is generally sloppy and indicates that the maintenance developer did not fully understand the code had just had to hack a fix in -- but if you have have ever had to maintain code it can be understandable if not maddening and frustrating for the next guy.

So while they are hardly ever used and MOST of the time when they are the code could probably be re-written without them -- they DO get used on rare occasions.

There are several reasons to avoid them:

#1 Creating a large set of unique and useful labels sucks
#2 Goto's lead to unstructured code and it can be very difficult to figure out the logical flow of the program. -- i.e. spaghetti code, no matter where you look its all a mess of this-way and that.
#3 goto's often lead to dead code blocks.
#4 goto's are often a maintenance nightmare -- looking back on code months after it was developed it can be very very difficult to rebuild the logical structure in your mind.
#5 goto's tend to be the harbingers of tiny logic errors which form hard to spot bugs (usually because the only thing wrong with the code is transposed lines or a mislabeled goto). -- the block structure is much better.

code should "speak" -- you should be able to read it and have it tell the story of what it does. The control structures offer much more structure and meaning to code and allows it to be read. You can tell where a while-loop begins, its easy to spot the beginning and end of an if-else block -- these kinds of structures are HARD to pick out with your eye using goto's.

When I need to figure out a section of assembly language I generally turn to a debugger and hope for the best... when I have to figure out a section of code that uses goto's -- generally I end up at a debugger as well -- but I am pretty sharp at parsing structured code.

Re: The demerits of goto

Posted 28 October 2009 - 10:47 AM

Gotos are useful in error handling; if you have multiple checks then you either end up nesting all those checks and reading/writing code with no end of whitespace on the left, or you invert the logic (which is confusing) and have multiple exits, which is fine if you *can* have multiple exits, or you have to invent a flag that has nothing to do with anything, set it when there's an error and keep testing it. With a goto, if a check fails you just goto the end of the function/logical section of code, or goto a block after the return that handles cleanup. But even this "need" is solved with exception handling.

Re: The demerits of goto

Posted 31 October 2009 - 11:10 AM

I would have to agree with gronk, while yes the main point is that it leads to unstructured programming when used to solve errors and for a small quick fix that can be changed later a Goto is actually quite convenient. Although some of my school assignments are pretty much paperweights when there's a Goto statement in them, I still find them useful in moderation.

Re: The demerits of goto

Posted 03 November 2009 - 10:39 PM

gotos are very useful while writing code in Embedded C++
There are other(saner) ways to do the same thing but makes shifting from assembly to c++ easier as both use labels
Bottom line : NOT Recommended for code other people would be reading and changing
Spaghetti code anyone?

Re: The demerits of goto

Posted 08 November 2009 - 12:26 PM

If they're used judiciously, i don't see much of a problem.

Usually i'll use them when you have a loop which might need to be exited for various reasons. Now, you could have an extra bool and set/reset/set/reset it and use continues, but sometimes i find it a whole heck of a lot easier to:

you can see how it can get complicated with more exit conditions, and then with more nested loops and saving exit codes it can get complicated. especially if condition happens to be ((c=a = b )-3*a)|0xFF!=e.

So, when you have nested loops and complex code, sometimes a goto can actually simplify things and allow more structure, instead of making things more complicated by having extra code just to handle the structure. Sometimes a single goto looks less like spaghetti then 50,000 if(cond)break; statements and a bunch of bools that nobody can seem to remember the meaning of...

Hey, C++ Standards Committee: Give us some sort of labeled break so we don't have to deal with all of these extraneous iffs and random break!

Re: The demerits of goto

Posted 18 November 2009 - 06:35 PM

Not to stir the pot again, but I can not think of a single instance, in a high level programming language, where I would use goto explicitly over a control structure or similar way of controlling program flow.

Re: The demerits of goto

Posted 25 November 2009 - 02:02 PM

as long as your code is easy to follow then why not have a goto? I use jmp statements in assembler and well document my code for easy follow. If I needed to use goto in C then I would well document what happens and why. In C++ however there is no need for a goto statement in any well thought out code.

In short I agree with Linus in the above link...don't let someone's personal preference dissuade you from doing what makes your code more efficient and more readable.

Re: The demerits of goto

From what i've seen, goto is primarily used for writing quick hassle-free fixes/enhancements to a bit of code where the developer is following the "if it ain't broke don't fix" philosophy;

In other words, they don't want to rewrite a largeish block of code because additional time will then need to go into peer reviewing and testing of code which may otherwise have not needed to change for a minor tweak.

This is a double-edged sword, because the existance of 1 goto in a block of code will often encourage future enhancements to be built in the same vein; Depending how often that function's logic needs to change, it doesn't take too long before a simple quick-fix gets messy. Eventually the day comes when something is so indecipherable and inter-locked with dependencies that rewriting it becomes a major task needing many development and testing hours.

just to illustrate what sometimes happens when several different developers get their hand on some 'goto' code, stealing Polymath's example (I've seen worse examples than this in production code...)

In an ideal world, I would always opt for re-designing away from 'goto' sooner rather than later (but of course business considerations trump technical ones). I can think of few people who would enjoy the task of tracing through dozens of lines of such code as you can see above.

Again, it comes down to individual programmers and their own judgement - if the boss wants something done 5 minutes ago, it might be a choice between a quick 'goto' fix and the boss having to explain to senior management why an airtight deadline worth £XXXXX has been put back by a day (In which case the boss will probably make that rather easy choice for you)

Re: The demerits of goto

In an ideal world, I would always opt for re-designing away from 'goto' sooner rather than later (but of course business considerations trump technical ones).

This is one of many areas where the typical short-term business mindset ends up costing more than it saves. Taking the time to do things right is the way to save money and time. Inserting a quick goto now may seem like a cost efficient solution, but the trouble it will cause later far offsets any short term gains.