Vale la pena usare goto?

gotoè quasi universalmente scoraggiato. Usare questa affermazione è mai utile?

Questo è stato discusso più volte su Stack Overflow e Chris Gillum ha riassunto i possibili usi digoto :

Uscire in modo pulito da una funzione

Spesso in una funzione, è possibile allocare risorse e dover uscire in più punti. I programmatori possono semplificare il loro codice inserendo il codice di pulizia delle risorse alla fine della funzione, tutti i "punti di uscita" della funzione dovrebbero andare sull'etichetta di pulizia. In questo modo, non è necessario scrivere il codice di pulizia in ogni "punto di uscita" della funzione.

Uscita da loop nidificati

Se sei in un ciclo nidificato e hai bisogno di uscire da tutti i loop, un goto può renderlo molto più pulito e più semplice delle dichiarazioni di interruzione e degli if-check.

Miglioramenti delle prestazioni di basso livello

Questo è valido solo nel codice perf-critico, ma le istruzioni goto vengono eseguite molto rapidamente e possono darti una spinta quando ti muovi attraverso una funzione. Questa è un'arma a doppio taglio, perché un compilatore in genere non può ottimizzare il codice che contiene gotos.

Direi, come molti altri affermerebbero, che in tutti questi casi, l'uso di gotoè usato come mezzo per uscire da un angolo in cui si è codificati, ed è generalmente un sintomo di codice che potrebbe essere riformulato.

I costrutti di flusso di controllo di livello superiore tendono a corrispondere ai concetti nel dominio del problema. Un if / else è una decisione basata su una condizione. Un loop dice di eseguire alcune azioni ripetutamente. Anche una dichiarazione di rottura dice "lo stavamo facendo ripetutamente, ma ora dobbiamo fermarci".

Un'istruzione goto, d'altra parte, tende a corrispondere a un concetto nel programma in esecuzione, non nel dominio del problema. Dice di continuare l'esecuzione in un punto specificato nel programma . Qualcuno che legge il codice deve dedurre cosa significa rispetto al dominio problematico.

Naturalmente tutti i costrutti di livello superiore possono essere definiti in termini di goto e semplici rami condizionali. Ciò non significa che siano semplicemente goto sotto mentite spoglie. Pensa a loro come goto limitate - ed è le restrizioni che le rendono utili. Un'istruzione break è implementata come un salto alla fine del ciclo che la racchiude, ma è meglio pensarla come operante sul ciclo nel suo insieme.

A parità di tutto il resto, il codice la cui struttura riflette quella del dominio problematico tende a essere più facile da leggere e mantenere.

Non ci sono casi in cui un'istruzione goto è assolutamente necessaria (c'è un teorema in tal senso), ma ci sono casi in cui può essere la soluzione meno negativa. Tali casi variano da una lingua all'altra, a seconda di quali costrutti di livello superiore siano supportati dalla lingua.

In C, ad esempio, credo che ci siano tre scenari di base in cui un goto è appropriato.

1. Uscire da un ciclo annidato. Ciò non sarebbe necessario se la lingua avesse un'istruzione break etichettata.
2. Salvataggio da un tratto di codice (in genere un corpo di funzione) in caso di errore o altro evento imprevisto. Ciò non sarebbe necessario se la lingua avesse eccezioni.
3. Implementazione di una macchina a stati finiti esplicita. In questo caso (e, penso, solo in questo caso) un goto corrisponde direttamente a un concetto nel dominio del problema, passando da uno stato a un altro stato specificato, in cui lo stato corrente è rappresentato da quale blocco di codice è attualmente in esecuzione .

D'altra parte, una macchina a stati finiti esplicita può anche essere implementata con un'istruzione switch all'interno di un ciclo. Ciò ha il vantaggio che ogni stato inizia nello stesso punto del codice, che può essere utile per il debug, ad esempio.

L'uso principale di un goto in un linguaggio ragionevolmente moderno (uno che supporta if / else e loop) è di simulare un costrutto del flusso di controllo che manca al linguaggio.

Sicuramente dipende dal linguaggio di programmazione. Il motivo principale gotoè stato controverso a causa dei suoi effetti negativi che sorgono quando il compilatore ti consente di usarlo troppo liberamente. Ad esempio, possono sorgere problemi se ti consente di utilizzare gotoin modo tale da poter ora accedere a una variabile non inizializzata, o peggio ancora, per passare a un altro metodo e pasticciare con lo stack di chiamate. Dovrebbe essere responsabilità del compilatore impedire il flusso di controllo senza senso.

Java ha tentato di "risolvere" questo problema impedendo del gototutto. Tuttavia, Java ti consente di utilizzare returnall'interno di un finallyblocco e quindi causare un'ingiunzione inavvertitamente. Lo stesso problema è ancora presente: il compilatore non sta facendo il suo lavoro. La rimozione gotodalla lingua non l'ha riparata.

In C #, gotoè sicuro come break, continue, try/catch/finallye return. Non ti consente di utilizzare variabili non inizializzate, non ti consente di saltare da un blocco finalmente, ecc. Il compilatore si lamenterà. Questo perché risolve il vero problema, che è come ho detto flusso di controllo senza senso. gotonon annulla magicamente l'analisi di assegnazione definita e altri controlli del compilatore ragionevoli.

Sì. Quando i tuoi loop sono nidificati a diversi livelli di profondità, gotoè l' unico modo per uscire elegantemente da un loop interno. L'altra opzione è quella di impostare un flag ed uscire da ciascun loop se quel flag soddisfa una condizione. Questo è davvero brutto e piuttosto soggetto a errori. In questi casi, gotoè semplicemente meglio.

Naturalmente, la breakdichiarazione etichettata di Java fa la stessa cosa, ma senza permetterti di saltare a un punto arbitrario nel codice, che risolve il problema in modo ordinato senza consentire le cose che fanno del gotomale.

La maggior parte dello scoraggiamento deriva da una sorta di "religione" che è stata creata suscitando Dio Djikstra che era irresistibile nei primi anni '60 per il suo potere indiscriminato di:

• saltare ovunque in qualsiasi blocco di codice
  • funzione non eseguita dall'inizio
  • loop non eseguiti dall'inizio
  • inizializzazione variabile saltata
• saltare lontano da qualsiasi blocco di codice senza alcuna possibile pulizia.

Ciò non ha più nulla a che fare con l' gotoaffermazione dei linguaggi moderni, la cui esistenza è semplicemente dovuta al supporto della creazione di strutture di codice diverse da quelle fornite dal linguaggio.

In particolare, il primo punto principale sopra è più consentito e il secondo viene ripulito (se si gotoesce da un blocco, lo stack viene svolto correttamente e tutti i distruttori appropriati vengono chiamati)

Puoi fare riferimento a questa risposta per avere un'idea di come anche il codice che non utilizza goto possa essere illeggibile. Il problema non è quello di andare in se stesso, ma il suo cattivo utilizzo.

Posso scrivere un intero programma senza usare if, solo for. Certo, non sarà ben leggibile, un aspetto goffo e inutilmente complicato.

Ma il problema non lo è for. Sono io.

Cose come break, continue, throw, bool needed=true; while(needed) {...}, ecc stanno notando più di mascherarsi goto per fuggire lontano dalle scimitarre degli Zeloti Djikstrarian, che -50 anni dopo l'invenzione della moderna laguages- vogliono ancora i loro prigionieri. Hanno dimenticato di cosa stava parlando Djikstra, ricordano solo il titolo della sua nota (GOTO considerato dannoso, e non era nemmeno il suo titolo onw: è stato modificato dall'editore) e la colpa e la bash, bash e la colpa di ogni contratto che hanno quei 4 lettera posta in sequenza.

È il 2011: è tempo di capire che gotoè importante notare l' GOTOaffermazione di cui Djikstra è stata avvincente.

Lo strano goto qui o là, purché sia ​​locale a una funzione, raramente danneggia significativamente la leggibilità. Ne beneficia spesso attirando l'attenzione sul fatto che in questo codice sta succedendo qualcosa di insolito che richiede l'uso di una struttura di controllo piuttosto rara.

Se i goto (locali) danneggiano significativamente la leggibilità, di solito è un segno che la funzione contenente il goto è diventata troppo complessa.

L'ultima goto che ho inserito in un pezzo di codice C è stata quella di costruire una coppia di anelli ad incastro. Non rientra nella normale definizione di utilizzo "accettabile", ma la funzione è risultata significativamente più piccola e più chiara di conseguenza. Per evitare il goto avrebbe richiesto una violazione particolarmente disordinata di DRY.

Penso che l'intero problema sia stato il caso di abbaiare l'albero sbagliato.

Il GOTO in quanto tale non mi sembra problematico, ma piuttosto spesso è un sintomo di un vero peccato: il codice spaghetti.

Se il GOTO causa l'attraversamento importante delle linee di controllo del flusso, allora non va bene, punto. Se non attraversa le linee di controllo del flusso è innocuo. Nella zona grigia in mezzo abbiamo cose come i salvataggi del ciclo, ci sono ancora alcune lingue che non hanno aggiunto costrutti che coprono tutti i casi grigi legittimi.

L'unico caso in cui mi sono ritrovato a usarlo effettivamente da molti anni è il caso del ciclo in cui il punto decisionale si trova nel mezzo del ciclo. Ti rimane un codice duplicato, una bandiera o un GOTO. Trovo la soluzione GOTO la migliore delle tre. Non vi è alcun incrocio di linee di controllo del flusso qui, è innocuo.

Sì, il goto può essere utilizzato a beneficio dell'esperienza dello sviluppatore: http://adamjonrichardson.com/2012/02/06/long-live-the-goto-statement/

Tuttavia, proprio come con qualsiasi strumento potente (puntatori, ereditarietà multipla, ecc.), Bisogna essere disciplinati usandolo. L'esempio fornito nel collegamento utilizza PHP, che limita l'utilizzo del costrutto goto alla stessa funzione / metodo e disabilita la possibilità di saltare in un nuovo blocco di controllo (ad es. Loop, istruzione switch, ecc.)

Dipende dalla lingua. È ancora ampiamente usato nella programmazione Cobol, per esempio. Ho anche lavorato su un dispositivo Barionet 50, il cui linguaggio di programmazione del firmware è un dialetto BASIC iniziale che ovviamente richiede l'uso di Goto.

Direi di no. Se trovi la necessità di utilizzare GOTO, scommetto che è necessario riprogettare il codice.

gotopuò essere utile quando si esegue il porting del codice dell'assemblatore legacy su C. In primo luogo, una conversione istruzione per istruzione in C, che utilizza gotocome sostituto branchdell'istruzione dell'assemblatore , può consentire il porting molto rapido.

Direi di no. Dovrebbero sempre essere sostituiti con uno strumento più specifico al problema che il goto viene utilizzato per risolvere (a meno che non sia disponibile nella tua lingua). Ad esempio, le dichiarazioni di interruzione e le eccezioni risolvono i problemi precedentemente risolti dall'escaping del loop e dalla gestione degli errori.