Ciò giustifica le dichiarazioni goto?

Mi sono imbattuto in questa domanda un secondo fa e sto estraendo parte del materiale da lì: esiste un nome per il costrutto "break n"?

Questo sembra essere un modo inutilmente complesso per le persone di dover istruire il programma a uscire da un doppio ciclo annidato:

for (i = 0; i < 10; i++) {
    bool broken = false;
    for (j = 10; j > 0; j--) {
        if (j == i) {
            broken = true;
            break;
        }
    }
    if (broken)
        break;
}

So che i libri di testo amano dire che le dichiarazioni goto sono il diavolo, e non mi piacciono affatto, ma ciò giustifica un'eccezione alla regola?

Sto cercando risposte che si occupano di n-nested per loop.

NOTA: Sia che tu risponda sì, no, o in qualche punto intermedio, le risposte completamente chiuse non sono benvenute. Soprattutto se la risposta è no, allora fornisci un motivo valido e legittimo (che non è comunque troppo lontano dai regolamenti di Stack Exchange).

L'apparente necessità di una dichiarazione di riferimento nasce da te che hai scelto espressioni condizionali povere per i loop .

Afferma di volere che il ciclo esterno continui per tutto il tempo i < 10e quello più interno continui per tutto il tempo j > 0.

Ma in realtà non è quello che volevi , semplicemente non hai detto ai loop la vera condizione che volevi che valutassero, quindi vuoi risolverlo usando break o goto.

Se dici ai loop le tue vere intenzioni per cominciare , allora non c'è bisogno di pause o goto.

bool alsoThis = true;
for (i = 0; i < 10 && alsoThis; i++)
{    
    for (j = 10; j > 0 && alsoThis; j--)
    {
        if (j == i)
        {
            alsoThis = false;
        }
    }
}

In questo caso, è possibile trasformare il codice in una routine separata e quindi solo returndal ciclo interno. Ciò negherebbe la necessità di uscire dal circuito esterno:

bool isBroken() {
    for (i = 0; i < 10; i++)
        for (j = 10; j > 0; j--)
            if (j == i) return true;

    return false;
}

No, non credo gotosia necessario. Se lo scrivi in ​​questo modo:

bool broken = false;
saved_i = 0;
for (i = 0; i < 10 && !broken; i++)
{
    broken = false;
    for (j = 10; j > 0 && !broken; j--)
    {
        if (j == i)
        {
            broken = true;
            saved_i = i;
        }
    }
}

Avere &&!brokensu entrambi i loop ti consente di uscire da entrambi i loop quando i==j.

Per me, questo approccio è preferibile. Le condizioni di loop sono estremamente chiari: i<10 && !broken.

Una versione funzionante è disponibile qui: http://rextester.com/KFMH48414

Codice:

public static void main(String args[])
{
    int i=0;
    int j=0;
    boolean broken = false;
    for (i = 0; i < 10 && !broken; i++)
    {
        broken = false;
        for (j = 10; j > 0 && !broken; j--)
        {
            if (j == i)
            {
                broken = true;
                System.out.println("loop breaks when i==j=="+i);
            }
        }
    }
    System.out.println(i);
    System.out.println(j);
}

Produzione:

il ciclo si interrompe quando i == j == 1
2
0

La risposta breve è "dipende". Consiglio di scegliere la leggibilità e la comprensibilità del codice. Il modo di andare in goto potrebbe essere più leggibile che modificare la condizione, o viceversa. Potresti anche prendere in considerazione il principio della minima sorpresa, le linee guida utilizzate nel negozio / progetto e la coerenza della base di codice. Ad esempio, goto per lasciare switch o per la gestione degli errori è una pratica comune nella base di codice del kernel Linux. Nota anche che alcuni programmatori potrebbero avere problemi a leggere il tuo codice (o sollevato con il mantra "goto is evil", o semplicemente non appreso perché il loro insegnante la pensa così) e alcuni di loro potrebbero persino "giudicarti".

In generale, è spesso accettabile andare avanti nella stessa funzione, soprattutto se il salto non è troppo lungo. Il tuo caso d'uso di lasciare un ciclo annidato è uno dei noti esempi di goto "non così malvagio".

Nel tuo caso, goto è abbastanza un miglioramento che sembra allettante, ma non è tanto un miglioramento che vale la pena infrangere la regola contro il loro utilizzo nella tua base di codice.

Pensa al tuo futuro recensore: dovrà pensare: "Questa persona è un cattivo programmatore o è in realtà un caso in cui valeva la pena andare al goto? Lasciami prendere 5 minuti per decidere da solo o ricercarlo sul Internet." Perché mai lo faresti al tuo programmatore futuro quando non puoi usare goto interamente?

In generale questa mentalità si applica a tutto il codice "cattivo" e persino lo definisce: se funziona ora, ed è buono in questo caso, ma crea uno sforzo per verificare che sia corretto, cosa che in questo periodo un goto farà sempre, quindi non farlo fallo.

Detto questo, sì, hai prodotto uno dei casi leggermente più spinosi. Potresti:

• utilizzare strutture di controllo più complesse, come una bandiera booleana, per uscire da entrambi i circuiti
• inserisci il tuo ciclo interno nella sua routine (probabilmente ideale)
• metti entrambi i loop in una routine e ritorna invece di rompere

È molto difficile per me creare un caso in cui un doppio loop non è così coeso che non dovrebbe comunque essere la sua routine.

A proposito, la migliore discussione di questo che ho visto è il Codice completo di Steve McConnell . Se ti piace pensare criticamente a questi problemi, ti consiglio vivamente di leggere, anche da copertina a copertina nonostante la sua immensità.

TLD; DR: No in particolare, sì in generale

Per l'esempio specifico che hai usato direi di no per gli stessi motivi che molti altri hanno sottolineato. Puoi facilmente riformattare il codice in una forma equivalentemente buona che elimina la necessità di goto.

In generale, la prescrizione contro gotoè una generalità basata sulla natura compresa gotoe sul costo del suo utilizzo. Parte dell'ingegneria del software sta prendendo decisioni di implementazione. La giustificazione di tali decisioni si verifica ponderando il costo rispetto ai benefici e ogni volta che i benefici superano i costi, l'attuazione è giustificata. La controversia sorge a causa di valutazioni diverse, sia in termini di costi che di benefici.

Il punto è che ci saranno sempre delle eccezioni in cui a gotoè giustificato, ma solo per alcuni a causa di valutazioni diverse. È un peccato che molti ingegneri semplicemente escludano le tecniche nell'ignoranza intenzionale perché le leggono su Internet piuttosto che prendersi il tempo per capire il perché.

Non credo che questo caso giustifichi un'eccezione, poiché può essere scritto come:

def outerLoop(){
    for (i = 0; i < 10; i++) {
        if( broken?(i) )
          return; // broken
    }
}

def broken?(i){
   for (j = 10; j > 0; j--) {
        if (j == i) {
            return true; // broken
        }
   }
   return false; // not broken
}