Can I know why is "goto" keyword considered under unused keyword

[karthikeya kumar]

Can I know why is "goto" keyword considered under unused keyword

[Winston Gutkowski]

karthikeya kumar wrote:Can I know why is "goto" keyword considered under unused keyword

Because it is almost always BAD, so the language tries to prevent it's use.

To find out why it's bad - although such eminent lights as K & R dispute this fact - look here.

Winston

[Les Morgan]

"goto" has been, for at least the last 25+ years been considered used in very sloppy programming. In OOP you would use another method, or in any programming language you would use an "if/then" with some encapsulation of code into a separate routine if the blocks were long. It is a hold over from the era of "spaghetti" code and a comfort for the old assembler programmers who are used to a branch always: "BRA".

karthikeya kumar wrote:Can I know why is "goto" keyword considered under unused keyword

[Winston Gutkowski]

Les Morgan wrote:"goto" has been, for at least the last 25+ years been considered used in very sloppy programming.

While I agree with you in general, several eminent experts - including Donald Knuth - do not.

There is also a fairly widely used algorithm that still uses it, because it makes the code optimally small and (according to the designers) easier to understand.

Winston

[Les Morgan]

Yes, I knew when I typed it that was going to get some flack, there are always exceptions to the rule. Back in the day I believe the statement was that "goto" was included in Java for completeness. Today we are pretty much free from "spaghetti code" though the industry frowning on using "goto".

In and of itself "goto" is not the culprit, bad programming is bad programming and if you enable the means to do really bad programming, then people are going to use it, and abuse it. Therein is the crux of why the industry had a shift to OOP and frowning on "goto".

Although now it seems that the industry is coming back around to looking at functional programming again.

Winston Gutkowski wrote:

Les Morgan wrote:"goto" has been, for at least the last 25+ years been considered used in very sloppy programming.

While I agree with you in general, several eminent experts - including Donald Knuth - do not.

There is also a fairly widely used algorithm that still uses it, because it makes the code optimally small and (according to the designers) easier to understand.

Winston

[Piet Souris]

Hmm, this brings some old and very new frustrations above...

First of all: it was around 1985 when I and some collegues were doing some update course econometrics at a real uni (of Amsterdam). We were given assignments, but, of course, Basic was strictly prohibited ('goto'!), we had to use Pascal. Now, that was a problem, because at the office we had a PDP with some Basic. After a lot of protesting, we finally were allowed to write our programs in Basic at the office (rumours have it that that prof was found later crying over his desk because of this 'humiliation').

But the most frustrating is: a program that allows 100% spaghetti code is seen as 'industry standard' and no one is complaining. I mean excel (or more generally: spreadsheets).
What about:

if('sheet A'!C27<>'sheet B'!aq99;'this sheet'!x32;if(...)

or, worse, at this very moment I'm staring at this monster:

=($D$21*(EXP(INDEX(scenario!$B$2:$BQ$53;E25+3;$C$21))-1)+$D$22*(EXP(INDEX(scenario!$B$2:$BQ$53;E25+3;$C$22))-1)+$D$23*(EXP(INDEX(scenario!$B$2:$BQ$53;E25+3;$C$23))-1)+$D$24*(EXP(INDEX(scenario!$B$2:$BQ$53;E25+3;$C$24))-1)+$D$25*(EXP(INDEX(scenario!$B$2:$BQ$53;E25+3;$C$25))-1)+$D$26*(EXP(INDEX(scenario!$B$2:$BQ$53;E25+3;$C$26))-1)+$D$28*(EXP(INDEX(scenario!$B$2:$BQ$53;E25+3;$C$28))-S25)+$D$29*(EXP(INDEX(scenario!$B$2:$BQ$53;E25+3;$C$29))-S25)+$D$30*(EXP(INDEX(scenario!$B$2:$BQ$53;E25+3;$C$30))-S25)+$D$31*(EXP(INDEX(scenario!$B$2:$BQ$53;E25+3;$C$31))-1)+$D$32*(EXP(INDEX(scenario!$B$2:$BQ$53;E25+3;$C$32))-1))

Yet we must use excel.

[Campbell Ritchie]

Winston Gutkowski wrote:. . . There is also a fairly widely used algorithm that still uses it, . . .

But aren't most such parsers created by automatic tools? Remember that code from automatic tools is exempt from all style conventions, so GOTO is probably permissible there. The Java® Language Specification (=JLS) says

The keywords const and goto are reserved, even though they are not currently used. This may allow a Java compiler to produce better error messages if these C++ keywords incorrectly appear in programs.

Kernighan and Ritchie, the C Programming Language, page 65 wrote:C provides the infinitely‑abusable goto statement, and labels to branch to. Formally, the goto is never necessary, and in practice it is almost always easy to write code without it. We have not used got in this book.
Nevertheless, there are a fwe situations where goto may find a place. The most common is to abandon processing in some deeply nested structure, such as breaking out of two or more loops at once. The break statement cannot be used directly since it only exits from the innermost loop. ...

This means that Bertrand Meyer was right to say in Object‑Oriented Sofware Construction that labelled break is a surrogate for goto.

[Winston Gutkowski]

Piet Souris wrote:But the most frustrating is: a program that allows 100% spaghetti code is seen as 'industry standard' and no one is complaining. I mean excel (or more generally: spreadsheets).
...
at this very moment I'm staring at this monster:
...
Yet we must use excel.

Says who?

That's your problem - PHB's; not Excel (or its kith and kin).

In general, spreadsheets do precisely what they were designed for - grid-based information and limited calculation - and do it very well.
It's when people try to use them as databases when the problems start.

Winston

[Tim Holloway]

Piet Souris wrote:
"goto" has been, for at least the last 25+ years been considered used in very sloppy programming.

Actually, it's been sloppy for a lot longer than that.

In the prehistoric days, computers were programmed by brute force using actual binary , assembly language, or Autocoder (a sort of high-level assembly language). At the machine level, the only way to transfer control was to do some sort of branch (goto) operation.

When higher-level languages came along - stuff like FORTRAN and COBOL, they inherited that sort of mechanism.

Branches are fine for small code modules, but the high-level procedural languages tended to end up as larger and more complex programs until the unrestricted transfer of control became a major problem. The number of possible logic paths increased exponentially and the number of pages of code to have to bounce between began to run to dozens of pages.

Edsger Djikstra was one of the computer science academics who studied the programming process and the architecture of code. He concluded that one of the major contributing factors to code that was unreliable and downright ugly was the "GOTO" statement and wrote a controversial paper about it somewhere around 1964 ("GOTO Considered Harmful").

Programming language designers took that as a challenge, and thus began the era of Structured Programming. Languages began to add high-level constructs that implemented logic flow control in a more managed way. There was an actual mathematical analysis done and a proof demonstrated that any program could be constructed solely from straight-line sequences, IF/THEN statements and conditional LOOP statements. Real-world implementations augmented this with subroutines (out-of-line sequences), DO-WHILE/FOR-EACH/REPEAT-UNTIL and SWITCH/CASE, but those are all conveniences that can be simulated with the basic 3 constructs.

Pure structured programming, however, causes nightmares of its own, as anyone who has seen code where nested IFs and LOOPs stack up and march across the page until the prettyprinted code stretches halfway to Alpha Centauri. So some shortcuts were created, such as the "break" and "return" statements. The problem with unrestricted GOTOs isn't simply that there's a jump to a far-off-place, but that goto-based code tends to weave in and out ("spaghetti code") according to the convenience of the programmer - who, if he/she is on an an optimization kick can get REALLY gnarly. The "break" and "return" statements take advantage of applying a method to the madness. You have simple rules that you can follow to determine where control ends up.

It has been found that a subroutine can be easy to follow if it has exactly one entry point even if it has multiple exit points (return statements), or multiple entry points but only a single exit point (I don't think any modern-day languages support this, but older FORTRAN did). Having both multiple entry points and multiple exit points, however, leads to spaghetti.

So, in short, both return and break statements are simply under-the-cover goto statements, but because they follow strict and predictable rules, you can safely (we hope!) write code that doesn't indent excessively.

Not everybody agrees with this idea. You can get into a lot of trouble, for example, if a subroutine is dotted with return statements, but for myself, I've adopted a compromise, which I call "filtered" methods where the first code elements in a subroutine determines whether the actual subroutine logic will be used and returns immediately if it does not. Some purists might insist that those sort of filters should be applied by the caller, not the subroutine, but there are cases where I don't want to depend on that, and in any case, if the subroutine is called from multiple points, it not only makes overall code bigger, it means multiple maintenance points.

Then there are Exceptions. Exceptions first became popular probably in the mid-1980s when they showed up in languages such as C++ and then Java. An Exception is a special type of subroutine return statement with an express route back upstream. Its immediate predecessor in C was the setjmp/longjmp kludge where code could record a high-level return point and then a low-level subroutine could do a longjmp to return to that point, unreeling the stack as it went. However, Exceptions improved on that concept by adding the ability to carry a payload back with them. And in the case of languages such as Java, additionally they added the structured "finally" statement to ensure that any intermediate resources that needed to be cleaned up could be handled.

So far I've just mentioned Structured Programming. However, when C++ came out, its major claim to fame was that it legitimized Object-Oriented programming. OOP is essentially just another way to make code more manageable by packaging related functions and data structured together instead of having them splattered all over the landscape.

[Winston Gutkowski]

Tim Holloway wrote:At the machine level, the only way to transfer control was to do some sort of branch (goto) operation.
When higher-level languages came along - stuff like FORTRAN and COBOL, they inherited that sort of mechanism.

However, even before that subroutines were always available, by pushing the return address onto a stack before jumping.

On balance, I agree with not allowing GOTOs; but the liberal in me still bristles at not being "trusted" to use them properly.

Winston

[Tim Holloway]

Winston Gutkowski wrote:

Tim Holloway wrote:At the machine level, the only way to transfer control was to do some sort of branch (goto) operation.
When higher-level languages came along - stuff like FORTRAN and COBOL, they inherited that sort of mechanism.

However, even before that subroutines were always available, by pushing the return address onto a stack before jumping.

On balance, I agree with not allowing GOTOs; but the liberal in me still bristles at not being "trusted" to use them properly.

Winston

I think I ran into at least one processor where a subroutine call had to be done by brute force, explicitly storing the return address and doing a machine-language branch. In fact, I believe that COBOL had a high-level version of this sort of construct. And then there was FORTRAN's Computed GOTO.

In a well-regulated shop, they don't want you to use GOTOs because while you might be trustworthy with them, too many other people couldn't be.

In a Shop from Hell, the Resident Genius+Management simply makes it a non-negotiable edict, even when it's more expensive not to use a GOTO.

[Mike Simmons]

Winston Gutkowski wrote:

Les Morgan wrote:"goto" has been, for at least the last 25+ years been considered used in very sloppy programming.

While I agree with you in general, several eminent experts - including Donald Knuth - do not.

To be fair though, I'm pretty sure that most (perhaps all?) of the GOTO uses that Knuth defended can be handled in Java by return, break, or continue. These seem to be pretty well accepted by most people nowadays, though one occasionally still encounters counterproductive zealots. Knuth seems to agree that unrestricted GOTO was in general a bad thing; he just argued for specific exceptions.

Well, on further thought, labelled break and continue are perhaps not so widely known and accepted in Java today. I can't remember the last time I've seen one in the wild. Probably we favor introducing intermediate methods instead to reduce nesting, so we rarely see the need.

[Tim Holloway]

I use continue as a variation of the "filtered method" in loops to determine what elements of an enumeration I actually want to process. It's a fairly common thing to do in C/C++ and shell scripts, although IIRC, somewhere around Java 7 or Java 8, "for" statements did add a filtering criteria right in the loop statement itself.

I also prefer to put labels on my loop break statements. Because I'm paranoid, not because I'm actually insane enough to want to break of of a multi-level loop

You just haven't been looking at the right person's code, that's all.

[Winston Gutkowski]

Tim Holloway wrote:I also prefer to put labels on my loop break statements. Because I'm paranoid, not because I'm actually insane enough to want to break of of a multi-level loop

Oh dear, Having your cake, but not eating it. Must be a singular existence.

I'm proud to say, I have never used a label, or a break statement in a loop, in any Java program I've ever written. And I write break statements grudgingly forswitch statements, but only because I have to - and I (still) often forget, which results in my first tests usually failing.

Winston

[Tim Holloway]

Well, my most common label is "loop", so I'll leave it to your imagination.

A break in a loop is a very common way to do things like find the index of the first/next item in a list/array that meets some sort of match criteria. You can't kludge the loop into premature termination by jamming the loop variable or you'll destroy the very information that you're looking for. You could do a return-with-value, but that's just a break with extreme prejudice. So by doing a "break" when you have a match you avoid spinning through the loop to no purpose. Although, alas, I've seen people do just that.

[Mike Simmons]

Tim Holloway wrote:A break in a loop is a very common way to do things like find the index of the first/next item in a list/array that meets some sort of match criteria. You can't kludge the loop into premature termination by jamming the loop variable or you'll destroy the very information that you're looking for.

Can't help but take this as a challenge:

  public static int findIndexInArray(int target, int[] array) {
    int i = array.length;
    while (--i >= 0)
      if (array[i] == target)
        i = -i;
    return -i - 1;
  }

Still, it's needlessly unclear; better to just break or return the index, as you noted.

Tim Holloway wrote:IIRC, somewhere around Java 7 or Java 8, "for" statements did add a filtering criteria right in the loop statement itself.

Are you thinking of the filter() method (and others) on streams, added in Java 8? Or something else?

  public static OptionalInt find(int target, int[] array) {
    return IntStream.of(array).filter(x -> x == target).findFirst();
  }

[Piet Souris]

Mike Simmons wrote:Can't help but take this as a challenge:

  public static int findIndexInArray(int target, int[] array) {
    int i = array.length;
    while (--i >= 0)
      if (array[i] == target)
        i = -i;
    return -i - 1;
  }

What does this method return when target is not found?

But what about what we learned in our very first java lesson?

  public static int findIndexInArray(int target, int[] array) {
    int i;
    boolean notFound = true;
    for (i = 0; i < array.length && notFound; i++) {
      if (array[i] == target) notFound = false;
     }
     return notFound ? -1 : i;
  }

[Winston Gutkowski]

Tim Holloway wrote:A break in a loop is a very common way to do things like find the index of the first/next item in a list/array that meets some sort of match criteria.

Ah, you'll notice I said break, not "a break". I use return all the time to terminate loops prematurely - particularly, as you say, for "finder" methods.

What I don't do is use break, and then write more logic to be performed after the loop.

Winston

[Winston Gutkowski]

Piet Souris wrote:But what about what we learned in our very first java lesson?

  public static int findIndexInArray(int target, int[] array) {
    int i;
    boolean notFound = true;
    for (i = 0; i < array.length && notFound; i++) {
      if (array[i] == target) notFound = false;
     }
     return notFound ? -1 : i;
  }

Ugh. I've never liked that style. Why not just:

public static int findIndexInArray(int target, int[] array) {
   for (int i = 0; i < array.length; i++) {
      if (array[i] == target)
         return i;
   }
   return -1;
}

?

And anyway, the last line of that code is wrong. It should be:
  return notFound ? -1 : i - 1;

Winston

[Les Morgan]

I've always liked to keep it to one exit point.

public static int findIndexInArray(int target, int[] array) {
   boolean bFound = false;
   for (int i = 0; i < array.length; i++) {
      if (array[i] == target){
         bFound = true;
         break;
      }
   }
   return bFound;
}

Winston Gutkowski wrote:
Ugh. I've never liked that style. Why not just:

public static int findIndexInArray(int target, int[] array) {
   for (int i = 0; i < array.length; i++) {
      if (array[i] == target)
         return i;
   }
   return -1;
}

?

[Mike Simmons]

Piet Souris wrote:

Mike Simmons wrote:Can't help but take this as a challenge:

  public static int findIndexInArray(int target, int[] array) {
    int i = array.length;
    while (--i >= 0)
      if (array[i] == target)
        i = -i;
    return -i - 1;
  }

What does this method return when target is not found?

Ah, good point - it's 0; I meant it to be -1. OK...

  public static int findIndexInArray(int target, int[] array) {
    int i = array.length;
    while (--i >= 0)
      if (array[i] == target)
        i = -i - 1;
    return -i - 2;
  }

So, as before: it's possible, but not very clear.

[Winston Gutkowski]

Les Morgan wrote:I've always liked to keep it to one exit point.]

What, so if you have a switch statement that could happily return a value from each case, you'll set that value to some internal variable and then break from each one just so you can have a single return statement?

I understand (most of) the reasons behind single returns, but I've never believed in slavish adherence to rules; and in the above case I reckon my code's clearer than yours;
I'm in a method that's looking for something; I've found it; so I return it...immediately...not in some other place because I'm not "allowed" to have more than one return statement.

But that's programming - and variety's the spice of life.

Winston

[Les Morgan]

Winston Gutkowski wrote:
What, so if you have a switch statement that could happily return a value from each case, you'll set that value to some internal variable and then break from each one just so you can have a single return statement?

Well, yes, but I would say a similar thing about your action where you have a return, in place of the break, for each and every one that is not a fall through condition.

Winston Gutkowski wrote:
I understand (most of) the reasons behind single returns, but I've never believed in slavish adherence to rules; and in the above case I reckon my code's clearer than yours;
I'm in a method that's looking for something; I've found it; so I return it...immediately...not in some other place because I'm not "allowed" to have more than one return statement.

But that's programming - and variety's the spice of life.

Winston

Yep, I usually do not begrudge any one style points, truth be told I have may quirks of my own in that department.

When I was first out of college I did maintenance on a client/server app that was AS-400 and Excel based. A lot of it was horrific spaghetti code filled with goto's and returns from almost any place in the code, and of course, no documentation and back in the day those were 13 or 14 inch screens. Well, after about a year of tracing through that mess, I found I was quite biased towards goto-less and single return point programming. As it turned out there were 3 developers that created the app, and by the time I was done, there was not even 1 line of code, overlay, or form that was left from one of the original developers--his coding really was that bad.

BTW: if memory serves correct there was a Winston back over on the Sun sites before they became "Oracle", that still leaves a bad taste in my mouth to say, be you that same person?

[Winston Gutkowski]

Mike Simmons wrote:Ah, good point - it's 0; I meant it to be -1. OK...

  public static int findIndexInArray(int target, int[] array) {
    int i = array.length;
    while (--i >= 0)
      if (array[i] == target)
        i = -i - 1;
    return -i - 2;
  }

So, as before: it's possible, but not very clear.

Am I missing something here? Surely

public static int findIndexInArray(int target, int[] array) {
   int i = array.length - 1;
   while(i >= 0 && array[i] != target) {
      --i;
   }
   return i;
}

will do the trick? (assuming this is meant to emulate lastIndexOf())
And it'll return -1 whenever target isn't found - including when array has 0 elements.

But maybe I'm just being thick...

Winston

[Winston Gutkowski]

Les Morgan wrote:BTW: if memory serves correct there was a Winston back over on the Sun sites before they became "Oracle", that still leaves a bad taste in my mouth to say, be you that same person?

Hmm. Well, I was certainly a contributor on the Oracle Java site before about 2011 when I found this one; so possibly.

But "bad taste"? I hope I didn't offend you over there. If I did, it wasn't intentional.

Winston

[Les Morgan]

Winston Gutkowski wrote:But "bad taste"? I hope I didn't offend you over there. If I did, it wasn't intentional.

Winston

Oh, not et all, not et all. The bad taste is that Sun became Oracle.

I see names from the "old guys" that were there back in the day, just nice to run across bits of familiarity here and there.

[Mike Simmons]

Winston Gutkowski wrote:
Am I missing something here?

No, your solution works too, and more clearly. I think I was reading something specific into Tim's comment about "You can't kludge the loop into premature termination by jamming the loop variable or you'll destroy the very information that you're looking for.", and I know realize I don't really know just what he meant by that anyway. Anyway, there are multiple ways to achieve it, unless Tim wants to clarify that he meant something different than what either of us have done.

[Liutauras Vilda]

Winston Gutkowski wrote:And it'll return -1 whenever target isn't found - including when array has 0 elements.

Nop line 2 still is a candidate for NullPointerException. I know I know... nitpicking, you're not discussing that here

[Mike Simmons]

I tend to think an NPE is the appropriate response if the array itself is null.

[Winston Gutkowski]

Liutauras Vilda wrote:Nop line 2 still is a candidate for NullPointerException. I know I know... nitpicking, you're not discussing that here

Fair point, but I tend to agree with Mike.

My thinking on NPE's is not to "let them happen" - ie, fail immediately, not "by default" three levels into some nested method.

However, there are two ways (at least) to do that:
1. Check for null explicitly and throw an exception.
2. Use the object immediately (and, of course, document that your method throws NPE).

I tend to favour the latter when it's possible - as in the above case - because it saves my old fingers,

But you're right; I could return -1 if the array is null, but IMO that's putting an interpretation on the meaning of "find" - and one that is potentially dangerous because it could mask a real problem.

My view is that, unless I'm told otherwise, or it has a specific meaning in the context it's used, null is always an error.

Winston

[Dave Tolls]

Les Morgan wrote:
I see names from the "old guys" that were there back in the day, just nice to run across bits of familiarity here and there.

We're all refugees...

[Liutauras Vilda]

Winston Gutkowski wrote:However, there are two ways (at least) to do that:
1. Check for null explicitly and throw an exception.
2. Use the object immediately (and, of course, document that your method throws NPE).

I always tend to think primarily about your 1st mentioned point, that is a must to check parameter for being null, and then act appropriately, either:

log with some kind of logging framework by providing some info about the origin of parameter and then throw exception explicitly

or just return where and if it is appropriate in case method type is void, maybe default value in case there is a return type specified

But I agree that your 2nd mentioned point would do the job too by documenting that part what is likely can happen. Without doing none of those, that makes think, that somehow programmer didn't think about such possible case at all.

[Ajoy Bhatia]

All replies here seem to be discussing why goto is good or bad. However, what I understood the original question to mean is (or at least, the question that I want the answer to is): Why is goto kept as a reserved keyword? If the only reason is to "discourage its use", just do not have that as a Java keyword at all. The Java language spec would not mention anything about goto and no Java compiler would implement it. I think that would surely "discourage its use". Why this attachment to keep the special status of the character sequence goto?

[Mike Simmons]

I interpreted the original question the same way you did - but I considered it to have already been answered by Campbell when he posted the relevant quote from JLS 3.9:

The keywords const and goto are reserved, even though they are not currently used. This may allow a Java compiler to produce better error messages if these C++ keywords incorrectly appear in programs.

In the early days of Java, C/C++ programmers were the main group of intended users, and they tried to make the migration process easier where possible. Since goto was legal in C/C++, but not Java, they at least tried to make it easier for C/C++ programmers to know what was wrong with their code. That's all there was to it.

[Ajoy Bhatia]

Oh, OK. Thanks, Mike. I just found this thread last night. I did skim through the replies but missed that.

[Vipin kumar sharma]

Its not safe that's why it is considered unused keyword.

[Ajoy Bhatia]

No, Vipin. The fact that goto is considered dangerous is the reason that Java does not support that language construct. However, the reason that the character sequence goto is given the special status of a keyword is explained in the JLS 3.9 quote in Mike Simmon's reply just before my previous comment.

[Ivan Jozsef Balazs]

Winston Gutkowski wrote:
I'm proud to say, I have never used a label, or a break statement in a loop, in any Java program I've ever written.

Labels can be fine; they allow this wonderful construct:

	public static void main(String args[]) {
		http://java.sun.com
		;
	} 

[Ivan Jozsef Balazs]

Ajoy Bhatia wrote:
Why is goto kept as a reserved keyword? If the only reason is to "discourage its use", just do not have that as a Java keyword at all. The Java language spec would not mention anything about goto and no Java compiler would implement it. I think that would surely "discourage its use".

Whereas this gets compiled fine:

	public static void main(String args[]) {
		int gogo = args.length;
	} 

This does not due to goto's being given a special treatment:

		int goto = args.length;

This discourages even using "goto" for any other purpose. You should not even think of using this four letter word.

[Winston Gutkowski]

Ivan Jozsef Balazs wrote:You should not even think of using this four letter word.

I like that: "'Goto' is a four-letter word" would have been a great title for an article by Edgar Dykstra. Or maybe someone else stole the idea before he could...

Winston