C# goto use - what else to use here?

Question

Hi, I know using goto is something most people say to avoid, however I have read on various places that sometimes it is useful if you need simple code. Currently I have very simple program that needs to be repeated if user selects so:

static void Main()
{
    Restart:
    ...

    string UserChoice=Console.ReadLine();
    if (UserChoice=="y")
    goto Restart;
}

Is using goto here really so bad? I just cannot see any other way how to repeat the code without doing loops etc. This seems to be very straightforward and clean way. Or am I missing something?

Answer 1

instead write something like below.

while(Console.ReadLine() == "y")
{
.....
}

Yes using goto is bad because it makes your code less readable.

Answer 2

Of course if your code is going to do the same thing again and again, you have to add a loop. That's much better than goto.

Use something like this

string UserChoice = "y";
while( UserChoice == "y"){
  ...
  UserChoice=Console.ReadLine();
}

That should work out well for you.

Answer 3

I'd use a do/while loop:

string UserChoice = "";
do {
    ...
    UserChoice=Console.ReadLine();
} while(UserChoice == "y");

Answer 4

You could use a recursive function to do the same without loops:

public static void Main(string[] args)
{
   PrintChoices();
}

private static void PrintChoices()
{
    string userChoice = Console.ReadLine();

    if (userChoice == "y")
        PrintChoices();        
}

Answer 5

Using methods instead of GOTOs is more widely accepted:

static void Main()
{
    Restart();
}

static void Restart()
{
    ...code

    string userChoice = Console.ReadLine();
    if (userChoice=="y")
        Restart();
}

Answer 6

Personally I have never had to use a goto, and like Øyvind Bråthen and Numenor have stated the loop method is by far the best way of doing this task.

However, there is one case that I can think of where a goto would be helpful

As a switch “fall through” is illegal in C# (causes a compiler error):

switch (a) 
{ 
    case 3: 
        b = 7; 
    case 4: 
        c = 3; 
        break; 
    default: 
        b = 2; 
        c = 4; 
        break; 
}

To get it to work you can use a goto:

switch (a) 
{ 
    case 3: 
        b = 7;
        goto case 4;
    case 4: 
        c = 3; 
        break; 
    default: 
        b = 2; 
        c = 4; 
        break; 
}

Answer 7

Use a do while loop to replace your goto as its much more readable.

do 
{
...
}
while(Console.ReadLine() == "y");

Answer 8

string userchoice;

do {                

    userchoice=Console.ReadLine();

} while (userchoice=="y");

Answer 9

There is one basic solution missing in the answers,

while (true)
{
    ...
    if (other-stop-condition) break;     

    ...

    string UserChoice=Console.ReadLine();
    if (UserChoice != "y") break;
}

The break statement is considered to be less structured than a pure while but more structured than a (real) goto. It should be used sparingly, but it has its uses like with the other-stop-condition

is using goto here really so bad?

Not in this simple program. But if you continue to use goto to replace loops, if/then etc your code will increase in complexity much faster than code that avoids goto.

Answer 10

I agree with Jimplode, Andreas the idea of forums is dissemination of information ideas, if you are not happy with what peoples ideas or opinions are, then dont take them on board.

Answer 11

Is using goto here really so bad?

In March 1968, Dijkstra sent a letter to Communications of the ACM which was published under the title Go To Statement Considered Harmful. It is an interesting read, and part of programmer lore.

The argument against GOTO presented in this letter has to do with how programmers build a mental model to track the progress of code execution. Dijkstra argues that such a mental model is important, because the value of variables is meaningful only relative to the execution progress. For example, when our program is counting the number of times an event occurs, there is always an in-between moment where N events have occurred, but the variable keeping track of it has not yet been incremented and is still at N-1.

He goes through these steps in his reasoning against GOTO:

1. First consider a very simple language without procedures, loops or GOTO. In such a language, the programmer can mentally track execution by imagining an execution pointer advancing from the start of the file to the end. A single index (i.e. the line number) suffices to model execution progress.

2. Now we add procedures to the language. The execution progress can no longer be tracked by a single index, as it might be inside a procedure. We also have to keep track from which line the procedure was called. Also, procedures can be called from other procedures. Therefore, we model execution progress as a sequence of indices. (In real life, programmers call such a sequence a "stack trace".)

3. Now we add loops to the language. For each line in our stack trace that is inside a loop body, we need to add another type of index to model execution progress: the repetition count.

4. Now we add GOTO. Dijkstra argues that with unbridled use of GOTO, our ability to track execution progress now breaks down. We can still track execution progress with an "execution clock" by saying "now we're executing the 152nd statement". However, this is not really helpful to establish the context that is necessary to interpret the values of variables.

As long as we only use GOTO statements to build simple loops, you can argue that the situation is equivalent to point (3), and there is no problem. But in that case you can just use the loop constructs. Better to just keep GOTO out of your code, so that you don't slip into the situation described in point (4).