[scratt]

Ok.. So it's Sunday and I like philosophical discussions on Sunday..

What's the general concensus about 'goto' here?

I know it's frowned upon, and I understand the age old predjudices against it... I suppose one way of looking at it from a low level programmers perspective is that it's kind of like leaving work without putting your tools away and tidying up...

But in the modern world of C and C++ is it really still an issue?

I, for one, do avoid it. But I cannot really see why we should. It's almost as if we've all decided it's bad without a really good reason. Read any text on C and C++ and you'll be told never to do it. It's bad, etc. etc. But never really given a reason..

How do you feel about using 'goto'..

And why?

[Barto]

It's bad because goto is spaghetti code. It's that simple. Rather than using easy to follow loops and function calls, or classes and objects in OO, you end up following the spaghetti thread for hours on end trying to figure out what's going on.

There's a lot of goto statements in the Mac OS X kernel, apparently there are legitimate uses for it in kernel code. According to the devs anyway.

[AsLan^]

I didn't even know there were goto statements in C++. Isn't that a BASIC thing ?

[ast3r3x]

I'd use it if I were making a really simple app or part of an app that was differentiated from everything else...but I would feel guilty.

[spotcatbug]

Goto got a bad rep when structured programming started taking over. Now it seems so obvious, but back then people would still use goto instead of breaking their code logic up into a hierarchy of procedure calls. The whole "no goto" thing was meant to stop that.

C++ does have constructs that break flow kinda like goto does: exceptions, return, break, continue. I use all of those often. I can't remember the last time I used a goto (in C++), but, if I found it absolutely necessary, I wouldn't mind doing it because I wouldn't be making spaghetti code with it. I would still try to avoid it (using exceptions, break, return or continue), though, simply because goto requires a label, which is slightly ugly and an extra step.

[scratt]

Originally Posted by AsLan^ I didn't even know there were goto statements in C++. Isn't that a BASIC thing ?

Cool. I love that comment. Yes, 'goto' is also a BASIC command.
But it does in deed exist in 'C++' too.

It's interesting that most people seem to agree there is no real harm in it, and objections are more to do with readability of code so far...

But we all still have it ingrained in us not to use 'goto'.

spotcatbug, you have the same view I do exactly. Both the view of break, continue etc. all having similar effects, and that a goto uses a label.

ast3r3x, I love it that you'd do it but feel guilty, as a few people who have voted have also said... It leaves me with a sort of grubby feeling when I look through code with it... But when I rationalise it I can see 'goto' is another equally valid style of programming, that does not necesarily lead to spagetti code... That is dependant on the programmer...

So perhaps that is why we are taught not to use it.. It's something which *may* lead to bad habits I suppose...

[hflomberg]

I havent seen this discussion since the mid 70's. Google "Goto's considered harmful" by Edsger Dyjkstra to find the original statement on the verb

[scratt]

Originally Posted by hflomberg I havent seen this discussion since the mid 70's. Google "Goto's considered harmful" by Edsger Dyjkstra to find the original statement on the verb

Cool article. Thanks.

goto linky

[thuh Freak]

the daily wtf

i've seen it used in c/c++ as a "fatal escape" from a function (personally i dont like exceptions, and i avoid them almost as much as gotos). like, when they'd done a whole lotta new's and malloc's at the head of a function, and throughout, and they hit a problem and needed to leave RSN. and they found there were like a bunch of times they needed to suddenly leave. so instead of copy and pasting all the delete's/free's, and possibly missing one and causing a leak, they put the cleanup at the end of a gotos. i don't much care for that as a choice; if you're gonna write dirty code (gotos are unclean in the eyes of the lord), why not make an ugly macro that has the cleanup job.

when i come across a piece of code that uses goto, i have less respect for the guy who wrote it. i have yet to concieve of a situation where goto would be the best option.

[Radarbob]

If one wrote a GOTO infested program and NEVER, ever, never had to read it or modify it then it would be perfectly OK. GOTOed code is all too often somewhere between a nightmare and literally impossible to modify. You'd really have to have the experience yourself to understand. And you must realize that GOTOs were typically used with a very "linear" or "unmodular" thought process - greatly compounding the problem. In effect GOTOs allowed the programmers to get away with *very poor* programming technique. For example, I "fondly" remember a single, highly nested IF statment that was a whole page long and had about 10 GOTOs in it. Bad programming + GOTO - a match made in hell.

Imagine doing auto maintenance and to change the spark plugs you the left rear wheel fell off. And when you jacked up the car to put the wheel back on, the radio would not work. And when you went to put the wheel back on it won't fit anymore.

That's nonsense, right? But that IS very much what it is like working on GOTO infested code. Modifying GOTO infested code tends to interrupt the original flow and so things "downstream", hundreds of lines (of code) away perhaps, don't work anymore.

Programs of any appreciable complexity thus become "unmaintainable." In my experience, we'd get a bug report. We would spend 3 days trying to understand the code flow, then make an educated guess and try a fix- that almost always caused the code to not works somewhere else. At times it felt like it was happening randomly. So we'd fix the original fix, tweak something else; then put the code back into production not really knowing if we did anything; hoping the users didn't report the error again.

What I just told you is not an exaggeration. And I recall the head of our accounting dept. telling me that they quit reporting bugs because they knew we simply could not fix them.

Finally I took the 4 worst programs and rewrote them. Rewriting from scratch was the only option. It took a year mostly because it was difficult in the extreme to understand what the original code was doing many times. When I was done, while I had added new functionality, was able to go from 4 programs to one, reduced the total amount of code by over 35% (even counting my new code that included hundreds of lines of inline comments (the original code, in it's several thousand lines, had zero comments)) and without any direct performance tweaking the program ran significantly faster.

[scratt]

You see. Now that kind of argument strikes me as almost extremeism.

I have seen a lot of code in my time. A lot of bad code, and a fair amount of good code..

The use of Goto in bad code has some of the symptoms that you talk about Radarbob, but in good, well documented, and well written code that is simply not the case.

Goto in code != bad code.

Not automatically.

The abundant use of Goto is often a sign of laziness so it may be true that goto shows up in bad code, but not because it itself is bad.

[Kickaha]

While true, I've yet to see a case of goto that wasn't grown after the fact into the code. What I mean is, a system is coded up, and later, functionality is added. Because the code is either hard to understand, or the later developer is a bit lazy, they use goto to either get around bad code, or because they just can't be bothered to do it right, *resulting* in bad code.

In either case, the end result is bad code.

Use of goto is a sign that the code needs to be carefully inspected and refactored, because *something* is either bad now, will soon be bad, or is bad masquerading as kewl under cover of a kludge.

[Enki]

Corrado Böhm and Guiseppe Jacopini presented the proof of the Structured Theorem which mathematically proved there are only 3 control structures required to write every possible program. ["Flow Diagrams, Turing Machines and Languages with Only Two Formation Rules", Communications of the ACM, No. 5, May 1966, pp 366-371.]

1) Sequential instructions. goto does not qualify as sequence because there is no guarantee the program will return to the next statement once that goto is followed.

2) Repitition structures, Do/while, but any particular loop implementation can be substituted for any other when combined with sequence and choice.

3) Choice structures, all types of which can be built out of arbitrarily complex if/then/else structure combinations.


That pretty much proves goto is NEVER required, because there is ALWAYS some other sane way to code it.

[scratt]

Originally Posted by Enki Corrado Böhm and Guiseppe Jacopini presented the proof of the Structured Theorem which mathematically proved there are only 3 control structures required to write every possible program. 1) Sequential instructions. goto does not qualify as sequence because there is no guarantee the program will return to the next statement once that goto is followed. 2) Repitition structures, Do/while but any particular loop implementation can be substituted for any other when combined with sequence and choice. 3) Choice structures, all types of which can be built out of arbitrarily complex if/then/else structure combinations. That pretty much proves goto is NEVER required, because there is ALWAYS some other sane way to code it.

That's really interesting. Do you have a link to any kind of article?

I guess it would be possible that you can write a program without anything really. I mean, it simply depends what level you are coding at.. There are a whole host of commands in C++ that we never had when we were writing in Assembler.. Does that proove we don't need them? Or more importantly does it proove we shouldn't ue them...

Don't get me wrong here. I do not like the thought of using goto, so I am not trying to advocate it's use here...

What I am trying to do is get to the bottom of the zealotry that surrounds the YOU MUST NOT USE GOTO edict. So in some ways I am going to argue it's case to see what people throw at the question..

From my low level roots big no nos in programming are things that leave the stack untidy, don't free up memory, overwrite areas of memory that we should not.. One big no no for a while in my early years was 'self-modyfying code'. Something I used all the time to get fast rendering on slow 8 bit processors without graphics processors... It's also something that we can do in C++ using pointers to functions and the like..

My point is I cannot find a reason other than aesthetic, or preference, which says that goto should not be used.

goto does not leave the stack messy. It does not cause huge piles of memory to leak away. In short I cannot find anything it does wrong, other than annoy us at the coding and text file level... That's why I am trying to get some viewpoints on this... And heck it's Sunday again...

[Kickaha]

Goto makes code hard to understand.

Code is, first and foremost, communication of intent: between the developer and the compiler, the developer and other developers, and the developer and a future self.

Goto makes the last two *much* more difficult. There's really no other reason needed.

The vast majority of more recent code constructs and commands are higher levels of abstraction, which allow the communication of much more intent than straight mathematical code... goto isn't. Goto adds zero additional abstraction, and just muddies flow control.

[scratt]

Originally Posted by Dr. Kickaha Goto makes code hard to understand.

How so?

Originally Posted by Dr. Kickaha Code is, first and foremost, communication of intent: between the developer and the compiler, the developer and other developers, and the developer and a future self. Goto makes the last two *much* more difficult. There's really no other reason needed.

Again, far be it for me to question the kind Doctor, but how so?

Originally Posted by Dr. Kickaha The vast majority of more recent code constructs and commands are higher levels of abstraction, which allow the communication of much more intent than straight mathematical code... goto isn't. Goto adds zero additional abstraction, and just muddies flow control.

'Muddies flow control'. Now you're just trying to bamboozel me with big words! Examples?

My reason for questioning all of this is it all still smacks of preference, and not a reasoned objection to goto with a smoking gun pointing to a case where goto is caught red handed with the lead bar standing behind Ms.Pink in the library..

I can read Assembly language programs, documented is easier I grant you, but without documentation also. I can figure out what they are doing.. So this objection to goto on the grounds it makes code hard to read, or hard to understand is a bit weak IMHO.

Heck there are some far harder really abstract bits of C++ that can be really hard to wrap your head around.. Take recursion for example.. Elegant solutions to some problems indeed.. But damn hard to visualise in your head and understand what the code is doing...

[Enki]

Originally Posted by scratt That's really interesting. Do you have a link to any kind of article?

I have a scan PDF of the original article if you really want your head to hurt. It's from the days when theoretical CS was still very much applied mathematics. The paper is from the time when BCPL was being developed from CPL, the first sustained large scale attempt to get past systems programming in assembler. That was two language generations before C which was really the first of the higher level languages. So that pretty much makes Böhm and Jacopini a seminal paper in how to even develop the higher level languages.

I guess it would be possible that you can write a program without anything really. I mean, it simply depends what level you are coding at.. There are a whole host of commands in C++ that we never had when we were writing in Assembler.. Does that proove we don't need them? Or more importantly does it proove we shouldn't ue them... Don't get me wrong here. I do not like the thought of using goto, so I am not trying to advocate it's use here... What I am trying to do is get to the bottom of the zealotry that surrounds the YOU MUST NOT USE GOTO edict. So in some ways I am going to argue it's case to see what people throw at the question.. From my low level roots big no nos in programming are things that leave the stack untidy, don't free up memory, overwrite areas of memory that we should not.. One big no no for a while in my early years was 'self-modyfying code'. Something I used all the time to get fast rendering on slow 8 bit processors without graphics processors... It's also something that we can do in C++ using pointers to functions and the like.. My point is I cannot find a reason other than aesthetic, or preference, which says that goto should not be used. goto does not leave the stack messy. It does not cause huge piles of memory to leak away. In short I cannot find anything it does wrong, other than annoy us at the coding and text file level... That's why I am trying to get some viewpoints on this... And heck it's Sunday again...

What all programming languages come down to are various ways to represent flow of control to human beings in shorthand that makes sense. Different folks like different shorthand. Those myriad of languages still do those 3 things in various combinations, designed to solve certain types of problems in certain styles compatible with the humans way of thinking about those problems. Sometimes the actual flow statements are hidden in the runtimes and the "program" the humans write is really the data, as in Prolog or SOAR and to some level, LISP.

The thing to really remember is the code typed in by humans is NOT written that way for the machine. It is written that way purely for human consumption. So any impediment to the clarity and quick understanding of the code is really an impediment to other humans who read it, and gets in the way of further writing or maintaining it. It's not that goto's create incorrect code, but they do make it much more difficult humans to follow the code.

goto's are really just a holdover from the days before higher level languages when programmers wrote in assembler and used JMP commands. Compilers and good assembler coders still generate code that uses JMP commands, but use the call-return stack frames to handle the proper sequential returning to the appropriate place in the original instruction stream. So compilers and well written assembler using the JMP do not create willy-nilly go anyplace code. Something todays higher level language coders using goto's are quite guilty of. That actually is making the call return stack untidy because it gets exceedingly difficult to ever return the departed frame, and that wastes the entire stack's worth of space below the frame that made the goto call.

Bottom line is it is more of a software engineering issue, than a pure CS theoretical correctness issue. The SWE sub-discipline is more concerned with verifiability and maintainability, which are both bottom line $$ per unit effort concerns and human effort is the most expensive over time. Use of programming structures that cause higher verification and maintenance expenditures for the same end product are highly frowned upon.

[scratt]

Originally Posted by Enki I have a scan PDF of the original article if you really want your head to hurt. It's from the days when theoretical CS was still very much applied mathematics. The paper is from the time when BCPL was being developed from CPL, the first sustained large scale attempt to get past systems programming in assembler. That was two language generations before C which was really the first of the higher level languages. So that pretty much makes Böhm and Jacopini a seminal paper in how to even develop the higher level languages.

Please. You can email it to me at my AN user name at gmail if you like..

=Enki]What all programming languages come down to are various ways to represent flow of control to human beings in shorthand that makes sense. Different folks like different shorthand. Those myriad of languages still do those 3 things in various combinations, designed to solve certain types of problems in certain styles compatible with the humans way of thinking about those problems. Sometimes the actual flow statements are hidden in the runtimes and the "program" the humans write is really the data, as in Prolog or SOAR and to some level, LISP. The thing to really remember is the code typed in by humans is NOT written that way for the machine. It is written that way purely for human consumption. So any impediment to the clarity and quick understanding of the code is really an impediment to other humans who read it, and gets in the way of further writing or maintaining it. It's not that goto's create incorrect code, but they do make it much more difficult humans to follow the code. goto's are really just a holdover from the days before higher level languages when programmers wrote in assembler and used JMP commands. Compilers and good assembler coders still generate code that uses JMP commands, but use the call-return stack frames to handle the proper sequential returning to the appropriate place in the original instruction stream. So compilers and well written assembler using the JMP do not create willy-nilly go anyplace code. Something todays higher level language coders using goto's are quite guilty of. That actually is making the call return stack untidy because it gets exceedingly difficult to ever return the departed frame, and that wastes the entire stack's worth of space below the frame that made the goto call. Bottom line is it is more of a software engineering issue, than a pure CS theoretical correctness issue. The SWE sub-discipline is more concerned with verifiability and maintainability, which are both bottom line $$ per unit effort concerns and human effort is the most expensive over time. Use of programming structures that cause higher verification and maintenance expenditures for the same end product are highly frowned upon.

I hear you. This kind of answers my question, or gives me the answer I already suspected. There is nothing wrong with it from a technical stand point. It is down to personal preferences (in real world terms - time and money).

I would love an example of a hard to read excerpt of code because of a goto though... Or are we saying code laced with goto's is bad? In which case I would agree as that would be as bad as code laced with if elses when switch would do the job, for example.

Perhaps it is my assembler background, but I still find all styles of code easy to read and understand.. So it really does not bother me... I know which I think is neater, but that does not mean it's bad code if it is untidy...

Again.. All of this is strictly IMHO.

[Radarbob]

A most lively and enjoyable discussion!

For the sake of argument I can concede that there is some decent code, somewhere, that has GOTOs. This just goes to show that there are exceptions to everything. Attempting to swim the english channel is not a good thing for 99.999% of us, but it's been done. anyway...

I say there is a technical issue with using GOTOs. It's a design issue, not a call stack or whatever issue. GOTOs introduce unwanted and undesireable code coupling.

I contend that "well written" code using GOTOs is bad design; and therefore not "well written". I think y'all are imagining a single GOTO in a few hundred lines of code. I'm talking about USING gotos. One program I rewrote had 79 GOTOs in a couple hundred lines of code. UNMAINTAINABLE, UNMAINTAINABLE, UNMAINTAINABLE. GOTOs make code changes very difficult to impossible. I was rewriting whole programs from scratch because I could not fix bugs - because of GOTOs.

Lots of gotos turns a program that might *look* like it's somewhat modular into a very long, monolithic, linear flow. When code jumps from the middle of one function (method, subroutine) to another, and another... You don't have separate functions anymore. You cannot manipulate the calls between the "separate" functions because the GOTOs force a certain code flow that completely detours around the function call and return mechanism. And upseting the goto house of cards (by trying to maintain your code) has a domino effect because GOTOs are making the code uncontrollable. Code becomes unmaintainable.

You can just see it in the "design thought process" behind the code. It simply is not thought out in a modular way.

Said another way, good programming doesn't require GOTOs. Conversersely, an indicator of bad code is lots of GOTOs. (which tends to be common in older code, from an era when programmers were taught to use goto).

Tracing Goto infested code is like being lost in a maze, going around and around and around, completely lost; not understanding WHY you're back at this stupid section of code again!

I'm getting too long winded here. It's hard to describe a horrible train wreck.

[hflomberg]

It's not just the Goto verb. as a matter of fact COBOL had an even worse mess called the "Alter" verb. The Structured Programming movement focused on the fact that coding was an engineering discipline and needed to adhere to a standardized structure. Code was a corporate asset!

Before this, programmers (and I was one of them) delighted in writing obscure code. Fortran contains a structure called an "An implied Do Loop" which, while massively efficient, is totally impossible to understand. Programmers used paragraph names such as "Scotch" and "Vodka". They used their childrens names. PL/I was an combination of the worst facets of COBOL and Fortran.

Honestly - I look at C code and think it's ugly, but then I started writing code before most of you were born. However today's development tools make the programmers of my day seem neanderthal by comparrison.

Amazing, at the tender age of 58 I've seen an entire industry (Cobol, mainframe development) start, peak and die.

[scratt]

Originally Posted by Radarbob When code jumps from the middle of one function (method, subroutine) to another, and another... You don't have separate functions anymore. You cannot manipulate the calls between the "separate" functions because the GOTOs force a certain code flow that completely detours around the function call and return mechanism. And upseting the goto house of cards (by trying to maintain your code) has a domino effect because GOTOs are making the code uncontrollable. Code becomes unmaintainable.

Interesting Radarbob...

When I was talking about 'gotos' I was referring to them being in the same routine... Jumping from sub-routine to sub-routine is totally unacceptable! My God! I cannot believe people would be that stupid!

To be honest I find it hard to believe anyone would use them that way! But I am sure there are people who do!

[drewprops]

Crap, I remember being baffled by the Implied Do Loop but more than that I remember running out of line numbers when I had to add stuff to my code. GOTOs were sometimes a sloppy, gloppy way to stick shit in. Tracking the path of logic through a long program could turn into a scavenger hunt if there were a lot of GOTOs in that sucker. Bah!

[Banana]

At my work, I develop Access database, so I do a bit of VBA. Curiously, Goto is used in error handling subroutines so a usual call would look like something

Function XOn Error Goto Sub_ErrorCode blah blah blahSub_ErrorMsgbox err blah blah blahGoto Exit_Function XSub_Exit_Function XExit FunctionEnd Sub

I later used a better error handling for the database that was written by a MVP, and it still used goto in that calls.

Would that be a exception to the rule or are Access developers morons? Erm... wait that's me!

[AsLan^]

This thread caused me to go do some reading the other day which found very interesting. Apparantley Pascal also has "computed" goto's which were even more fun for people. I imagine you would use a goto were it made semantic sense to do so (easier to read), and didn't obfuscate the code.

After reading through the thread I think that goto's should be used similar to breaks. The other "no-no". From what you read online a break is almost is as bad as a goto, why not just set the exit condition to your loop when that condition has been met... well in some loops, "break" just looks better.

Here is an example I just came across last night in fact.

for (i = 0; i < 5; i++){        if (this > that[i])         {                   do something that I only want done once...                                  break         }}

To rewrite that without a break would mean you had to set i to five and the loop would exit normally. But what if I later wanted to change the number of iterations from 5 to 10, I would have to remember to change it in the loop as well. And, at first glance, it might not be clear to everyone reading the code that setting i to five is actually what's causing the loop to exit. That break, is very easy to read. I agree you shouldn't get out of hand with breaks but in that particular case, break looked better (to my eyes) than setting the exit condition. I've come across examples like this every now and then.

There must be some situation that warrants using a goto ? but perhaps because there are so few situations in which a goto would be easier to read, it's best that nobody use them, lest they be ridiculed (unless they are programming access databases, and then anything goes).

[scratt]

Originally Posted by AsLan^ for (i = 0; i < 5; i++) { if (this > that[i]) { do something that I only want done once... break } }

WHAT THE HELL ARE ALL YOUR CURLY BRACKETS DOING ON THE SAME VERTICAL LINE... RAARRARARARARRARAARRAAAAAAAAAAAAAA!

[AsLan^]

Originally Posted by scratt WHAT THE HELL ARE ALL YOUR CURLY BRACKETS DOING ON THE SAME VERTICAL LINE... RAARRARARARARRARAARRAAAAAAAAAAAAAA!

It took out my whitespace !

Fixed

[spotcatbug]

Originally Posted by AsLan^ for (i = 0; i < 5; i++){ if (this > that[i]) { do something that I only want done once... break }} To rewrite that without a break would mean you had to set i to five and the loop would exit normally.

Changing the for-loop variable inside the loop, IMO, would be a much, much worse offense than using that break. If you really wanted to avoid using the break, you should introduce another variable, "done" (or somesuch), which you set to true and check in the loop condition (along with i). I would just use the break, however.

[scratt]

Oh my God! An extra variable, just as a flag!

What an outrageous waste of memory!!

[AsLan^]

I just remembered reading somewhere that you *shouldnt* use breaks because they are technically un-needed in the three control methods.

I just thought I'd mention it because, goto seems to fall in to the same boat and the argument sometimes used (other than it can obfuscate the code) is that it is also un-necessary.

[Mr Beardsley]

I don't see any problem with breaking out of a loop early. The way you access items in an array is to loop over the array, and do a check for the item that you want. When you find the item that you want, you might was well stop looking, especially if you have a really large array.