C# goto use - che altro usare qui?

Question

So che usare goto è qualcosa che la maggior parte della gente dice di evitare, tuttavia ho letto su vari punti che a volte è utile se hai bisogno di un codice semplice. Attualmente ho molto semplice programma che deve essere ripetuta se l'utente seleziona quindi:

static void Main() 
{ 
    Restart: 
    ... 

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

sta usando goto qui davvero così male? Non riesco a vedere altro modo su come ripetere il codice senza fare cicli ecc. Questo sembra essere un modo molto semplice e pulito. O mi sta sfuggendo qualcosa?

Answer 1

string userchoice; 

do {     

    userchoice=Console.ReadLine(); 

} while (userchoice=="y"); 

Answer 2

invece scrivere qualcosa di simile qui di seguito.

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

Sì, utilizzare goto non è corretto perché rende il codice meno leggibile.

Answer 3

Ovviamente se il codice farà sempre la stessa cosa, è necessario aggiungere un ciclo. È molto meglio di goto.

Usa qualcosa come questo

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

che dovrebbe funzionare bene per voi.

Answer 4

userei un do/while:

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

Answer 5

è possibile utilizzare una funzione ricorsiva per fare lo stesso senza loop:

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

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

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

Answer 6

Utilizzando metodi invece di GOTO è più ampiamente accettati :

static void Main() 
{ 
    Restart(); 
} 

static void Restart() 
{ 
    ...code 

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

Answer 7

Personalmente non ho mai dovuto usare un goto, e come Øyvind Bråthen e Númenor hanno dichiarato il metodo loop è di gran lunga il modo migliore per eseguire questa operazione.

Tuttavia, v'è un caso che mi viene in mente in cui un goto sarebbe utile

come un interruttore “caduta attraverso” è illegale in C# (causa un errore di compilazione):

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

per farlo funzionare è possibile utilizzare un goto:

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

Answer 8

utilizzare un ciclo Do while per sostituire il vostro goto come la sua molto più leggibile.

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

Answer 9

C'è una soluzione di base mancante nelle risposte,

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

    ... 

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

La dichiarazione break è considerato meno strutturato di un puro po ', ma più strutturato di un (vero) goto. Dovrebbe essere usato con parsimonia, ma ha i suoi usi come con lo other-stop-condition

sta usando goto qui davvero così male?

Non in questo semplice programma. Ma se continui a utilizzare goto per sostituire i loop, se/allora ecc. Il tuo codice aumenterà di complessità molto più rapidamente del codice che evita lo goto.

Answer 10

Utilizzare goto qui è davvero così brutto?

nel marzo 1968, Dijkstra inviato una lettera al Communications of the ACM che è stato pubblicato con il titolo Go To Statement Considered Harmful. È una lettura interessante e parte della tradizione dei programmatori.

L'argomento contro GOTO presentato in questa lettera ha a che fare con il modo in cui i programmatori costruiscono un modello mentale per tracciare l'avanzamento dell'esecuzione del codice. Dijkstra sostiene che un tale modello mentale è importante, perché il valore delle variabili è significativo solo in relazione al progresso dell'esecuzione. Ad esempio, quando il nostro programma conta il numero di volte in cui si verifica un evento, c'è sempre un momento intermedio in cui si sono verificati eventi N, ma la variabile che ne tiene traccia non è stata ancora incrementata ed è ancora a N-1.

Egli passa attraverso questi passaggi nel suo ragionamento contro GOTO:

1. prima prendere in considerazione un linguaggio molto semplice senza procedure, loops o GOTO. In tale linguaggio, il programmatore può monitorare mentalmente l'esecuzione immaginando un puntatore di esecuzione che avanza dall'inizio del file fino alla fine. Un singolo indice (ovvero il numero di riga) è sufficiente per modellare l'avanzamento dell'esecuzione.

2. Ora aggiungiamo procedure alla lingua. L'avanzamento dell'esecuzione non può più essere monitorato da un singolo indice, come potrebbe essere all'interno di una procedura. Dobbiamo anche tenere traccia da quale linea è stata chiamata la procedura. Inoltre, le procedure possono essere chiamate da altre procedure. Pertanto, modelliamo l'andamento dell'esecuzione come una sequenza di indici. (Nella vita reale, i programmatori chiamano tale sequenza "stack trace".)

3. Ora aggiungiamo loop alla lingua. Per ogni riga nella nostra traccia di stack che si trova all'interno di un corpo del ciclo, è necessario aggiungere un altro tipo di indice per modellare l'avanzamento dell'esecuzione: il conteggio della ripetizione.

4. Ora aggiungiamo GOTO. Dijkstra sostiene che con l'uso sfrenato di GOTO, la nostra capacità di tracciare i progressi di esecuzione ora si interrompe. Possiamo ancora tenere traccia dell'avanzamento dell'esecuzione con un "clock di esecuzione" dicendo "ora stiamo eseguendo la 152esima istruzione". Tuttavia, questo non è veramente utile per stabilire il contesto che è necessario per interpretare i valori delle variabili.

Finché usiamo solo istruzioni GOTO per costruire loop semplici, si può sostenere che la situazione è equivalente a punto (3), e non c'è nessun problema. Ma in quel caso puoi semplicemente usare i costrutti del ciclo. Meglio tenere GOTO fuori dal tuo codice, in modo da non scivolare nella situazione descritta al punto (4).