Is using goto a bad practice

Sad enough to say, my first experiences in programming were on a TI-83+ calculator. And as some of you may know labels and goto were the closest you could get to OOP on one of those. But that was then, this is now. Would you guys/girls agree (with my professor...) that using labels and gotos in C++ is a bad programming practice?

Quote:

---

Originally Posted by phosphorus

Would you guys/girls agree (with my professor...) that using labels and gotos in C++ is a bad programming practice?

---

I would say that "excessive" use of "gotos" is bad practice. There are however a coupld of cases where "goto's" are imho the best alternative, the most prominent one being the possibility to abort nested loops. Example:

Code:

---

void f()
{
  for (i = 0; i < 10; i++) {
    for (j = 0; j < 10; j++) {
      // do something
      if (...) {
        // abort both loops
        goto afterloops;
      }
    }
  }
  afterloops:
  // do something more
}

---

treuss, I tend to disagree with your example and, in my opinion, your way shows why goto's should be avoided at every instance - its lazy programming practice.

The code that you used as an example can easily avoid goto's, but does require extra effort in terms of thinking:

Code:

---

void f()
{
  for (i = 0; i < 10; i++) {
    for (j = 0; j < 10; j++) {
      // do something
      if (...)
      {
        i=10;  // or 9
        break;
      }
    }
  }
  // do something here
}

---

This will still achieve what you want without the goto statement.

All in all, goto's should be avoided at all costs and there should be no reason for it.... in all my experience I have never used them and anyone who has, has been frowned up on.

Just my $0.02 worth

Regards

Quote:

---

Originally Posted by Vaderman

This will still achieve what you want without the goto statement.

---

Except that your codes behaves differently.

If the values of i and j are needed for further processing you'll need a third variable storing the value of i.

- petter

The great goto debate ...

http://www.codeguru.com/forum/showthread.php?t=214449

Quite true wildfrog. :thumb:

Regards

This thread has "flame war" written all over it :)

Quote:

---

Originally Posted by phosphorus

Would you guys/girls agree (with my professor...) that using labels and gotos in C++ is a bad programming practice?

---

No, gotos are an invaluable tool for making your code unintelligible to other programmers and introducing subtle and hard to find bugs. Why would you want to give that up?

Seriously, there's a problem in C++ with gotos that they may skip over constructor calls, so at the target of the goto you are in a situation where a variable is in scope but hasn't been constructed. Fortunately, most compilers will warn you about this so you can avoid it. Other than that - feel free to use gotos. The more, the merrier.

Quote:

---

Originally Posted by Vaderman

All in all, goto's should be avoided at all costs and there should be no reason for it.... in all my experience I have never used them and anyone who has, has been frowned up on.

---

I have never used them; but in hindsight, I think my prejudice against goto was mere superstition. There is no harm done if it results in more readable code.

Quote:

---

Originally Posted by Vaderman

Code:

---

void f()
{
  for (i = 0; i < 10; i++) {
    for (j = 0; j < 10; j++) {
      // do something
      if (...)
      {
        i=10;  // or 9
        break;
      }
    }
  }
  // do something here
}

---

---

"break" does not take you out of both loops.

Quote:

---

Originally Posted by Philip Nicoletti

The great goto debate ...

---

That was 4 years ago. I think it's time for a new one ;)

break does not break you out of both loops. You're correct on that point. Never suggested that it would. ;)

It will break out of the inner loop and since i=10 (or 9) it will then break out of the outer loop.

Regards

Quote:

---

Originally Posted by Vaderman

treuss, I tend to disagree with your example and, in my opinion, your way shows why goto's should be avoided at every instance - its lazy programming practice.

The code that you used as an example can easily avoid goto's, but does require extra effort in terms of thinking:

---

It is of course your good right to disagree with me but I do not consider your example better code than mine. Your example is imho a good example of what oddities programmers sometimes code, just for the sake of avoiding gotos.

Yes you can always avoid gotos. Just as you can always avoid for-loops, or do-while constructs. Just, for what sake?

If you look at our both code examples and think away any comment, my example is very self-documenting (goto afterloops), while yours will put a beginner programmer (or someone who reads over the code too quickly) at problem, because "i=10;" is not a very common neither clear way to end a loop, "i=9;" is probably even worse (though more correct).

So, this is my opinion, as stated you have the full right to disagree (would be boring if all agreed on the same thing).

Quote:

---

Originally Posted by Sahir

That was 4 years ago. I think it's time for a new one ;)

---

Why, the C++ standard hasn't changed since 1998 ;)

I have never used a goto in any *production* program that I have written. I have avoided them at all cost and written complex loops to get around using them.

Having said that, I believe that goto statements do have their place and are not by definition "bad". I think that there have been 1 or 2 times that I should have used a goto when I didn't because I was told by other programmers/books/professors that they are bad.

Another "bad programming practice" that I think is more accepted now is having more than 1 return from a function. This one I really don't worry about at all. Just as long as the code makes sense, then I don't worry about how many returns statements are in a single function call. In fact, It is much more difficult to code a single return, when multiple returns make sense, than to code a loop (or something else) when a goto makes sense.

Sincerely,
Kendall

Quote:

---

Originally Posted by Sahir

[...] There is no harm done if it results in more readable code.

---

The problem is that you've just described the null set.

In Javascript (ECMA Script 3. ed) you got break and continue statements just as in C/C++, but in addition you can add an optional label to the keyword:

Code:

---

continue [label];

---

and

Code:

---

break [label];

---

Code:

---

outerloop:
while (a)
{
    while (b)
    {
        if (someCondition)
            break outerLoop;
    }
}

---

This seems like an attempt to avoid the use of goto and other messy code to break/continue nested loops. What do you anti-goto'ers out there think of such a construct?

- petter