Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. The Lounge
  3. Where Is IntelliSense For "goto" statements?

Where Is IntelliSense For "goto" statements?

Scheduled Pinned Locked Moved The Lounge
visual-studiocsharptutorialquestion
58 Posts 28 Posters 13 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • N Nish Nishant

    Richard Blythe wrote:

    I've been trying to dig up a good example of me using the "goto" statement. However, in most cases, I would probably get a pile of contradictory replys.

    Here's one case where "some people" think it's okay:

    private static void Foo(int x)
    {
    Console.WriteLine(String.Concat("Option: ", x));

    switch (x)
    {
        case 0:
            Console.WriteLine("English");
            goto case 1;
    
        case 1:
            Console.WriteLine("Spanish");
            break;
    
        default:
            Console.WriteLine("English");
            break;
    }
    
    Console.WriteLine();
    

    }

    And here's the refactored goto-less version:

    private static void AltFoo(int x)
    {
    Console.WriteLine(String.Concat("Option: ", x));

    switch (x)
    {
        case 0:
            DisplayEnglish();
            DisplaySpanish();                
            break;
    
        case 1:
            DisplaySpanish();                
            break;
    
        default:
            DisplayEnglish();
            break;
    }
    
    Console.WriteLine();
    

    }

    private static void DisplaySpanish()
    {
    Console.WriteLine("Spanish");
    }

    private static void DisplayEnglish()
    {
    Console.WriteLine("English");
    }

    Regards, Nish


    Blog: blog.voidnish.com Most recent article: An MVVM friendly approach to adding system menu entries in a WPF application

    C Offline
    C Offline
    cgh1977
    wrote on last edited by
    #36

    Sorry.. I see the case you are trying to make, but in this specific case there is a simpler goto-less construct:

    private static void AltFoo(int x)
    {
    Console.WriteLine(String.Concat("Option: ", x));

    if (x != 1)
    {
        Console.WriteLine("English");
    }
    if (x == 0 || x == 1)
        Console.WriteLine("Spanish");
    }
    
    Console.WriteLine();
    

    }

    I expect your response will be something along the line of 'extend the example to more complex cases and the if-then approach becomes unwieldy'. Granted. Of the three examples (mine and your two), your second example is the best solution. It is considerably easier to understand and is more maintainable. Suppose the specification adds support for three other languages: French, German, and Italian. The goto version becomes impossible (without a lot of convoluted spaghetti code), but this code is very clear:

    private static void AltFoo(int x)
    {
    Console.WriteLine(String.Concat("Option: ", x));

    switch (x)
    {
        case 0:
            DisplayEnglish();
            DisplaySpanish();
            DisplayGerman();
            DisplayItalian();
            break;
    
        case 1:
            DisplaySpanish();
            break;
    
        case 2:
            DisplayGerman();
            break;
    
        case 3:
            DisplayItalian();
            break;
    
        default:
            DisplayEnglish();
            break;
    }
    
    Console.WriteLine();
    

    }

    private static void DisplayItalian()
    {
    Console.WriteLine("Italian");
    }

    private static void DisplayGerman()
    {
    Console.WriteLine("German");
    }

    private static void DisplaySpanish()
    {
    Console.WriteLine("Spanish");
    }

    private static void DisplayEnglish()
    {
    Console.WriteLine("English");
    }

    N 1 Reply Last reply
    0
    • L Luc Pattyn

      a goto in some decompilation output does not prove there was a goto in the original source; it could be the decompiler did not recognize the original (looping) construct. In the end, every construct that changes the program flow is bound to get translated in an elementary jump/goto/branch/call/return instruction. :)

      Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum

      Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.

      C Offline
      C Offline
      chrissb
      wrote on last edited by
      #37

      This may be heresy, but is optimising yourself feasible? In which case goto would be allowed.

      1 Reply Last reply
      0
      • R Richard Blythe

        I don't use the: "goto" statement very often but I have started using it more frequently. Does anyone know why Visual Studio does not implement IntelliSense for goto statements? For example: // VS code editor does not show IntelliSense with //available "Label_" when entering this goto statement if (condition == true) goto Label_ExitCode; //... Label_ExitCode: //...

        The mind is like a parachute. It doesn’t work unless it’s open.

        C Offline
        C Offline
        chrissb
        wrote on last edited by
        #38

        Off topic. :P First thought is, wouldn't it be quicker to type goto than to use intellisense anyway? You hit "g", all available commands starting with G show up, then you select the one you want, then hit enter. Three key presses assuming it's top of the list, otherwise it would be easier to just type it up. It would be like waiting for intellisense to give you the IF command instead of just typing it. Amusing if I'm observing, useless otherwise.

        E 1 Reply Last reply
        0
        • R RichardM1

          Please, just take it to another thread!

          Opacity, the new Transparency.

          A Offline
          A Offline
          Avatar_generic
          wrote on last edited by
          #39

          Or conversely the non serious could just goto hell.

          B R 2 Replies Last reply
          0
          • M Mycroft Holmes

            PIEBALDconsult wrote:

            modern languages have more robust sets of flow control

            Absolutely, I can't understand why it has not been, what's that word, deprecated. For the life of me I can't think of a reason for it to be there, I wonder if GoSub is still in there as well.

            Never underestimate the power of human stupidity RAH

            E Offline
            E Offline
            englebart
            wrote on last edited by
            #40

            To answer the poster: Here are some reasons why I would not if I was writing the IDE on a deadline: I wonder if some Microsoft developer could post the number of "goto" statements present in the VS 2010 code base. This might be a hint. If there is not a huge number, I would love to know how many goto statements were used that were NOT for exiting an inner loop. 0. Assumption: gotos are rarely used. 1. Assumption: A goto will only be used to break a nested loop. This means that you will type "goto done;" and a few seconds later type "done:". 2. Assumption: each label will only be referenced once (maybe twice) 3. Assumption: It will probably be a short label. (e.g. done: ) 4. Assumption: A developer will never do this more than once (maybe twice) in a C# method. If they need more than one label, they will probably split the method up. 5. Given: The label is always local to a method. (You are not trying to retrieve a property or method from some object that you did not write) 6. Given: If you type the goto and label so that they mismatch, the compiler will catch it. See #2 and #7. 7. Given: If the IDE developer goes through all of the trouble to give a list of valid labels, and you select the WRONG label, you are just as screwed as if you had typed the wrong label! 8. Given: Workaround: Since it is local editing, just use Copy+Paste. Closed - Feature Not Needed.
            P.S. Java killed the goto via the break [label]; and continue [label]; statements. goto is a Java reserved word, but also a compile error. C# decided to follow C++ and keep goto;

            1 Reply Last reply
            0
            • C chrissb

              Off topic. :P First thought is, wouldn't it be quicker to type goto than to use intellisense anyway? You hit "g", all available commands starting with G show up, then you select the one you want, then hit enter. Three key presses assuming it's top of the list, otherwise it would be easier to just type it up. It would be like waiting for intellisense to give you the IF command instead of just typing it. Amusing if I'm observing, useless otherwise.

              E Offline
              E Offline
              englebart
              wrote on last edited by
              #41

              I think he means, type goto ! ! = Now give me my label.

              C 1 Reply Last reply
              0
              • C cgh1977

                Sorry.. I see the case you are trying to make, but in this specific case there is a simpler goto-less construct:

                private static void AltFoo(int x)
                {
                Console.WriteLine(String.Concat("Option: ", x));

                if (x != 1)
                {
                    Console.WriteLine("English");
                }
                if (x == 0 || x == 1)
                    Console.WriteLine("Spanish");
                }
                
                Console.WriteLine();
                

                }

                I expect your response will be something along the line of 'extend the example to more complex cases and the if-then approach becomes unwieldy'. Granted. Of the three examples (mine and your two), your second example is the best solution. It is considerably easier to understand and is more maintainable. Suppose the specification adds support for three other languages: French, German, and Italian. The goto version becomes impossible (without a lot of convoluted spaghetti code), but this code is very clear:

                private static void AltFoo(int x)
                {
                Console.WriteLine(String.Concat("Option: ", x));

                switch (x)
                {
                    case 0:
                        DisplayEnglish();
                        DisplaySpanish();
                        DisplayGerman();
                        DisplayItalian();
                        break;
                
                    case 1:
                        DisplaySpanish();
                        break;
                
                    case 2:
                        DisplayGerman();
                        break;
                
                    case 3:
                        DisplayItalian();
                        break;
                
                    default:
                        DisplayEnglish();
                        break;
                }
                
                Console.WriteLine();
                

                }

                private static void DisplayItalian()
                {
                Console.WriteLine("Italian");
                }

                private static void DisplayGerman()
                {
                Console.WriteLine("German");
                }

                private static void DisplaySpanish()
                {
                Console.WriteLine("Spanish");
                }

                private static void DisplayEnglish()
                {
                Console.WriteLine("English");
                }

                N Offline
                N Offline
                Nish Nishant
                wrote on last edited by
                #42

                cgh1977 wrote:

                I see the case you are trying to make

                cgh1977 wrote:

                I expect your response will be something along the line

                Actually, I don't really use gotos, and was merely throwing in a generally pushed point of view, hence the use of "some people" in my first sentence. And in my example, I'd always choose the goto-less version or some similar variant.

                Regards, Nish


                Blog: blog.voidnish.com Most recent article: An MVVM friendly approach to adding system menu entries in a WPF application

                1 Reply Last reply
                0
                • E englebart

                  I think he means, type goto ! ! = Now give me my label.

                  C Offline
                  C Offline
                  chrissb
                  wrote on last edited by
                  #43

                  Ah, that makes more sense.

                  1 Reply Last reply
                  0
                  • A Avatar_generic

                    Or conversely the non serious could just goto hell.

                    B Offline
                    B Offline
                    Bob1000
                    wrote on last edited by
                    #44

                    and finaly goto TOP agggghhh

                    1 Reply Last reply
                    0
                    • R RichardM1

                      Please, just take it to another thread!

                      Opacity, the new Transparency.

                      A Offline
                      A Offline
                      Alex Lyman
                      wrote on last edited by
                      #45

                      throw a hissy-fit, whydoncha?

                      R 1 Reply Last reply
                      0
                      • A Alex Lyman

                        throw a hissy-fit, whydoncha?

                        R Offline
                        R Offline
                        RichardM1
                        wrote on last edited by
                        #46

                        try and catch this hissy-fit

                        Opacity, the new Transparency.

                        1 Reply Last reply
                        0
                        • A Avatar_generic

                          Or conversely the non serious could just goto hell.

                          R Offline
                          R Offline
                          RichardM1
                          wrote on last edited by
                          #47

                          foreach non serious person, I will throw up on them. then they can go where ever they want

                          Opacity, the new Transparency.

                          1 Reply Last reply
                          0
                          • G glennPattonWork3

                            Hi, Not a proper softy (I'm a hardware guy who programs on occasion) I have used a goto only in RTOS situations where if the program counter/accumlator goes beyond a certain point it will make a whole in the wall as it goes beyond reach. I was one of the spagetti basic guys who gave the goto a bad rep. It's just a way of moving around the memory so thats why the .NET compilers use it (or a jmp or jump instruction) it's only when people who didn't know what it was or how to use it got involved did it get a bad reputation. Glenn (let the abuse begin!)

                            R Offline
                            R Offline
                            RichardM1
                            wrote on last edited by
                            #48

                            I totally agree with you. Goto is used everywhere by everyone, right now, in C#, but it is abstracted to look like more complex statements. Goto can be a powerful tool in the right situation, especially in native c/c++. I agree that a lot of programmers could really screw up a pile of mud if they were given powerful tools, but I don't think that means you outlaw back-hoes. It means you smack the hand of the ones who run with scissors around others, or go ahead and poke them in the eye so they know the consequences. Allow me to protect me from myself. Don't force me to be protected from myself.

                            Opacity, the new Transparency.

                            1 Reply Last reply
                            0
                            • L Leslie Sanford

                              Richard Blythe wrote:

                              I've been trying to dig up a good example of me using the "goto" statement.

                              I haven't used goto's, but my understanding is that they can be helpful in error handling, e.g. goto HandleError. It allows you to write code after such goto statements in such a way that it can assume that no error has occurred, thus simplifying things. One could argue that this is what exceptions are for. But the same reasoning that says that goto's are bad would seem to apply to exceptions, maybe even more so. Using goto to jump ahead within a function to execute some error handling code would seem less confusing than throwing the control flow completely out of the current context to who knows where.

                              T Offline
                              T Offline
                              Theraot
                              wrote on last edited by
                              #49

                              That was a good point, and that's why we use pokémon error handling: to put a limit to that who knows where. The gotta catch'all approach is good when calling third party code in particular when it has the potential to be wrote letter by who knows who. By the way, I browsed my more relevant solution for an use of goto, and found only one, and I'm proud of it:

                                  \[DebuggerNonUserCode()\]
                                  private static int Sqrt(int number)
                                  {
                                      //Newton's method aproximation for positive integers
                                      //if (n == 0) return 0;
                                      int x, \_x = number >> 1;
                                  back:
                                      x = (\_x + number / \_x) >> 1;
                                      if (x <= \_x) return \_x;
                                      \_x = x;
                                      goto back;
                                  }
                              

                              I did my best at that time to increase performance of that code without going to a non-portable solution. I wonder if anybody will find a better way to write it.

                              1 Reply Last reply
                              0
                              • D Dave Kreskowiak

                                Richard Blythe wrote:

                                I don't use the: "goto" statement very often but I have started using it more frequently.

                                >SMACK!!< You what? :| I haven't found a need for a GOTO in the last, oh, 15 years...

                                A guide to posting questions on CodeProject[^]
                                Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
                                     2006, 2007, 2008
                                But no longer in 2009...

                                A Offline
                                A Offline
                                Antzzz
                                wrote on last edited by
                                #50

                                Dave Kreskowiak wrote:

                                >SMACK!!< You what? I haven't found a need for a GOTO in the last, oh, 15 years...

                                You've obviously never coded in C for a low power micro with no exception handling... GOTO has it uses - mostly for bailing out to a common exit point when something goes pearshaped and you need to clean up after yourself. Only other option in these circumstances is horribly nested if statements - using a GOTO results in much cleaner/readable code. A TRY/CATCH block would do the trick nicely, but most low power (I'm not talking ARMs here, old crusty Renesas M16s and the like) micros used in industry don't have exception handling.

                                D 1 Reply Last reply
                                0
                                • R Richard Blythe

                                  I don't use the: "goto" statement very often but I have started using it more frequently. Does anyone know why Visual Studio does not implement IntelliSense for goto statements? For example: // VS code editor does not show IntelliSense with //available "Label_" when entering this goto statement if (condition == true) goto Label_ExitCode; //... Label_ExitCode: //...

                                  The mind is like a parachute. It doesn’t work unless it’s open.

                                  S Offline
                                  S Offline
                                  Sergelp
                                  wrote on last edited by
                                  #51

                                  Ever heard of try/catch - if then else ... Goto usage is the ultimate spaghetti type programming, so you don't want to go that way. It's not a crusade, it's a fact. Believe me - a former spaghetti analyser that has programmed for years in language like Data General/UBB (Universal Business BASIC). For a long time in those languages (interpreter based) the "do while/for loop" instruction didn't exist and every line in your program had a linenumber. With the goto you could force a kind of do while or even if then else. Also a goto made the program go faster (interpreter) skipping the lines that it didn't needed. The goto was of course abused making the readability very poor. Here's an example of a do while in old BASIC 100 if i<10 then 110 ... (instruction) 120 ... 130 ... 140 goto 100 150 end if Gradually the linenumber became labels and vb3,vb4,... took on this way of programming. @start 100 if i<10 then 110 ... 120 goto @start 130 end if Those (nostalgic) days are gone now... :-) I think the only reason why MS didn't completely erase the command is backwards compatibility with VB6 where you had to use it with (on) error handling. Now you have an (even better) initiative for this, the try/catch/finaly block. The finaly part is certainly an improvement. Conclusion : "Spaghetti is nice as long as it's on your plate accompagnied with some tomatoesauce, cheese and some tabasco".

                                  modified on Tuesday, July 13, 2010 5:20 AM

                                  R 1 Reply Last reply
                                  0
                                  • R Richard Blythe

                                    I don't use the: "goto" statement very often but I have started using it more frequently. Does anyone know why Visual Studio does not implement IntelliSense for goto statements? For example: // VS code editor does not show IntelliSense with //available "Label_" when entering this goto statement if (condition == true) goto Label_ExitCode; //... Label_ExitCode: //...

                                    The mind is like a parachute. It doesn’t work unless it’s open.

                                    B Offline
                                    B Offline
                                    Bujar Tahiri
                                    wrote on last edited by
                                    #52

                                    Richard Blythe wrote:

                                    I don't use the: "goto" statement very often but I have started using it more frequently. Does anyone know why Visual Studio does not implement IntelliSense for goto statements?

                                    Try it in VB, maybe C# does not have it

                                    1 Reply Last reply
                                    0
                                    • S Sergelp

                                      Ever heard of try/catch - if then else ... Goto usage is the ultimate spaghetti type programming, so you don't want to go that way. It's not a crusade, it's a fact. Believe me - a former spaghetti analyser that has programmed for years in language like Data General/UBB (Universal Business BASIC). For a long time in those languages (interpreter based) the "do while/for loop" instruction didn't exist and every line in your program had a linenumber. With the goto you could force a kind of do while or even if then else. Also a goto made the program go faster (interpreter) skipping the lines that it didn't needed. The goto was of course abused making the readability very poor. Here's an example of a do while in old BASIC 100 if i<10 then 110 ... (instruction) 120 ... 130 ... 140 goto 100 150 end if Gradually the linenumber became labels and vb3,vb4,... took on this way of programming. @start 100 if i<10 then 110 ... 120 goto @start 130 end if Those (nostalgic) days are gone now... :-) I think the only reason why MS didn't completely erase the command is backwards compatibility with VB6 where you had to use it with (on) error handling. Now you have an (even better) initiative for this, the try/catch/finaly block. The finaly part is certainly an improvement. Conclusion : "Spaghetti is nice as long as it's on your plate accompagnied with some tomatoesauce, cheese and some tabasco".

                                      modified on Tuesday, July 13, 2010 5:20 AM

                                      R Offline
                                      R Offline
                                      Richard Blythe
                                      wrote on last edited by
                                      #53

                                      My primary reason is for complex validation that share the same exception. Here's an example:

                                      public void validateSomething(someComplexType)
                                      {
                                      if (first_conditionFails)
                                      goto Label_Error;
                                      else if (complexAlgorithmRequired)
                                      {
                                      //init vars for algorithm...
                                      if (first_conditionFails)
                                      goto Label_Error;
                                      else if (second_conditionFails)
                                      goto Label_Error;
                                      else //perform second phase of algorithm
                                      {
                                      //init vars for second phase...
                                      if (first_conditionFails)
                                      goto Label_Error;
                                      else if (second_conditionFails)
                                      goto Label_Error;
                                      }
                                      }
                                      //skip the end-of-routine error code
                                      return;

                                      Label_Error:
                                      //set class vars...
                                      //to an invalid state...
                                      //...
                                      throw new someException();
                                      }

                                      How would you implement this with try/catch without a whole bunch of "throw someException()"?

                                      The mind is like a parachute. It doesn’t work unless it’s open.

                                      E S 2 Replies Last reply
                                      0
                                      • R Richard Blythe

                                        My primary reason is for complex validation that share the same exception. Here's an example:

                                        public void validateSomething(someComplexType)
                                        {
                                        if (first_conditionFails)
                                        goto Label_Error;
                                        else if (complexAlgorithmRequired)
                                        {
                                        //init vars for algorithm...
                                        if (first_conditionFails)
                                        goto Label_Error;
                                        else if (second_conditionFails)
                                        goto Label_Error;
                                        else //perform second phase of algorithm
                                        {
                                        //init vars for second phase...
                                        if (first_conditionFails)
                                        goto Label_Error;
                                        else if (second_conditionFails)
                                        goto Label_Error;
                                        }
                                        }
                                        //skip the end-of-routine error code
                                        return;

                                        Label_Error:
                                        //set class vars...
                                        //to an invalid state...
                                        //...
                                        throw new someException();
                                        }

                                        How would you implement this with try/catch without a whole bunch of "throw someException()"?

                                        The mind is like a parachute. It doesn’t work unless it’s open.

                                        E Offline
                                        E Offline
                                        engchin
                                        wrote on last edited by
                                        #54

                                        You can put the codes under Label_Error in a separate function, say CatchError(). Then, replace every line of your goto label_error statement with a statement calling the CatchError function. This would be much more readable and at the same time avoid all the pitfalls of goto.

                                        1 Reply Last reply
                                        0
                                        • R Richard Blythe

                                          My primary reason is for complex validation that share the same exception. Here's an example:

                                          public void validateSomething(someComplexType)
                                          {
                                          if (first_conditionFails)
                                          goto Label_Error;
                                          else if (complexAlgorithmRequired)
                                          {
                                          //init vars for algorithm...
                                          if (first_conditionFails)
                                          goto Label_Error;
                                          else if (second_conditionFails)
                                          goto Label_Error;
                                          else //perform second phase of algorithm
                                          {
                                          //init vars for second phase...
                                          if (first_conditionFails)
                                          goto Label_Error;
                                          else if (second_conditionFails)
                                          goto Label_Error;
                                          }
                                          }
                                          //skip the end-of-routine error code
                                          return;

                                          Label_Error:
                                          //set class vars...
                                          //to an invalid state...
                                          //...
                                          throw new someException();
                                          }

                                          How would you implement this with try/catch without a whole bunch of "throw someException()"?

                                          The mind is like a parachute. It doesn’t work unless it’s open.

                                          S Offline
                                          S Offline
                                          Sergelp
                                          wrote on last edited by
                                          #55

                                          Hi Richard, I didn't know for for what purpose you were trying to use the goto that's why I assumed it was for as try catch system (is the most common use). On your case it's not the try/catch that has to be used. How I would solve this problem, is by using validationfunction with a return value. This way you could even put your validation in a separate class or library. It's a standalone function. Best practice to seperate this because if your using winforms, you could easily use the same validation when you decide to use ASP.net or something else. Compile the lib as a dll, put the function public and you can use it in any language. The enum is practical in .net because the intellisense kicks in but you could easily test it on the values 1,2,3 In fact you could consider the return value as a kind of a label. I'll put it in VB because I know this best but you'll get the idea. Enum ValidateError firstcondition = 1 secondcondition = 2 thirdcondition = 3 End Enum Private Sub ValidateMessage(ByVal someComplexType) Select Case ValidateSomething(someComplexType) Case ValidateError.firstcondition MsgBox("first") Case ValidateError.secondcondition MsgBox("second") Case ValidateError.thirdcondition MsgBox("third") Case Else MsgBox("ok") End Select End Sub Private Function ValidateSomething(ByVal someComplexType) As ValidateError If someComplexType < 0 Then Return ValidateError.firstcondition End If If someComplexType > 100 Then Return ValidateError.secondcondition End If If someComplexType > 1000 Then If someComplexType > 2000 Then Return ValidateError.thirdcondition End If End If '... End Function What do you think of it ? Regards Serge

                                          1 Reply Last reply
                                          0
                                          Reply
                                          • Reply as topic
                                          Log in to reply
                                          • Oldest to Newest
                                          • Newest to Oldest
                                          • Most Votes


                                          • Login

                                          • Don't have an account? Register

                                          • Login or register to search.
                                          • First post
                                            Last post
                                          0
                                          • Categories
                                          • Recent
                                          • Tags
                                          • Popular
                                          • World
                                          • Users
                                          • Groups