Cambia istruzione fall-through ... dovrebbe essere consentito? [chiuso]

Per tutto il tempo che posso ricordare ho evitato di utilizzare la fall-through delle istruzioni switch. In realtà, non riesco a ricordare che sia mai entrato nella mia coscienza come un possibile modo di fare le cose poiché mi è stato perforato nella testa all'inizio che non era altro che un bug nella dichiarazione di cambio. Tuttavia, oggi mi sono imbattuto in un codice che lo utilizza in base alla progettazione, il che mi ha fatto chiedere immediatamente cosa pensano tutti nella comunità del fall-through dell'istruzione switch.

È qualcosa che un linguaggio di programmazione non dovrebbe consentire esplicitamente (come fa C #, sebbene fornisca una soluzione alternativa) o è una caratteristica di qualsiasi linguaggio che è abbastanza potente da lasciare nelle mani del programmatore?

Modifica: non ero abbastanza specifico per ciò che intendevo per fall-through. Uso molto questo tipo:

    switch(m_loadAnimSubCt){
        case 0:
        case 1:
            // Do something
            break;
        case 2:
        case 3:
        case 4:
            // Do something
            break;
   }

Tuttavia, sono preoccupato per qualcosa di simile.

   switch(m_loadAnimSubCt){
        case 0:
        case 1:
            // Do something, but fall through to the other cases
            // after doing it.

        case 2:
        case 3:
        case 4:
            // Do something else.
            break;
   }

In questo modo ogni volta che il caso è 0, 1 farà tutto nell'istruzione switch. L'ho visto in base alla progettazione e non so se sono d'accordo che le istruzioni switch dovrebbero essere usate in questo modo. Penso che il primo esempio di codice sia molto utile e sicuro. Il secondo sembra piuttosto pericoloso.

Può dipendere da ciò che consideri fallimentare. Sto bene con questo genere di cose:

switch (value)
{
  case 0:
    result = ZERO_DIGIT;
    break;

  case 1:
  case 3:
  case 5:
  case 7:
  case 9:
     result = ODD_DIGIT;
     break;

  case 2:
  case 4:
  case 6:
  case 8:
     result = EVEN_DIGIT;
     break;
}

Ma se hai un'etichetta di case seguita da codice che ricade su un'altra etichetta di case, lo considererei quasi sempre male. Forse spostare il codice comune in una funzione e chiamare da entrambi i punti sarebbe un'idea migliore.

E tieni presente che utilizzo la definizione di "male" delle FAQ in C ++

È un'arma a doppio taglio. A volte è molto utile, ma spesso pericoloso.

Quando va bene? Quando vuoi che 10 casi vengano elaborati tutti allo stesso modo ...

switch (c) {
  case 1:
  case 2:
            ... Do some of the work ...
            /* FALLTHROUGH */
  case 17:
            ... Do something ...
            break;
  case 5:
  case 43:
            ... Do something else ...
            break;
}

L'unica regola che mi piace è che se fai qualcosa di stravagante dove escludi l'interruzione, hai bisogno di un commento chiaro / * FALLTHROUGH * / per indicare che era la tua intenzione.

Hai sentito del dispositivo di Duff ? Questo è un ottimo esempio di utilizzo di switch fallthrough.

È una funzionalità che può essere utilizzata e può essere abusata, come quasi tutte le funzionalità del linguaggio.

Il fall-through è davvero una cosa utile, a seconda di cosa stai facendo. Considera questo modo chiaro e comprensibile per organizzare le opzioni:

switch ($someoption) {
  case 'a':
  case 'b':
  case 'c':
    // Do something
    break;

  case 'd':
  case 'e':
    // Do something else
    break;
}

Immagina di farlo con if / else. Sarebbe un casino.

Può essere molto utile alcune volte, ma in generale, nessun fall-through è il comportamento desiderato. Il fall-through dovrebbe essere consentito, ma non implicito.

Un esempio, per aggiornare vecchie versioni di alcuni dati:

switch (version) {
    case 1:
        // Update some stuff
    case 2:
        // Update more stuff
    case 3:
        // Update even more stuff
    case 4:
        // And so on
}

Mi piacerebbe una sintassi diversa per i fallback negli interruttori, qualcosa come, errr ..

switch(myParam)
{
  case 0 or 1 or 2:
    // Do something;
    break;
  case 3 or 4:
    // Do something else;
    break;
}

Nota: questo sarebbe già possibile con le enumerazioni, se dichiari tutti i casi sulla tua enumerazione usando i flag, giusto? Neanche suona così male; i casi potrebbero (dovrebbero?) essere già parte della tua enumerazione.

Forse questo sarebbe un bel caso (nessun gioco di parole) per un'interfaccia fluente che utilizza metodi di estensione? Qualcosa come, ehm ...

int value = 10;
value.Switch()
  .Case(() => { /* Do something; */ }, new {0, 1, 2})
  .Case(() => { /* Do something else */ } new {3, 4})
  .Default(() => { /* Do the default case; */ });

Anche se probabilmente è ancora meno leggibile: P

Come qualsiasi cosa: se usato con cura, può essere uno strumento elegante.

Tuttavia, penso che gli svantaggi più che giustificano il non usarlo e infine non consentirlo più (C #). Tra i problemi ci sono:

• è facile "dimenticare" una pausa
• non è sempre ovvio per i manutentori del codice che un'interruzione omessa fosse intenzionale

Buon uso di un interruttore / caso di caduta:

switch (x)
{
case 1:
case 2:
case 3:
 Do something
 break;
}

Baaaaad uso di un interruttore / caso di caduta:

switch (x)
{
case 1:
    Some code
case 2:
    Some more code
case 3:
    Even more code
    break;
}

Questo può essere riscritto usando i costrutti if / else senza alcuna perdita a mio parere.

La mia ultima parola: stai lontano dalle etichette casuali casuali come nel cattivo esempio, a meno che tu non stia mantenendo il codice legacy in cui questo stile è usato e ben compreso.

È potente e pericoloso. Il problema più grande con il fall-through è che non è esplicito. Ad esempio, se ti imbatti in un codice modificato di frequente che ha un interruttore con fallimenti, come fai a sapere che è intenzionale e non un bug?

Ovunque lo uso, mi assicuro che sia commentato correttamente:

switch($var) {
    case 'first':
        // Fall-through
    case 'second':
        i++;
        break;
 }

Usare il fall-through come nel tuo primo esempio è chiaramente OK e non lo considererei un vero fall-through.

Il secondo esempio è pericoloso e (se non ampiamente commentato) non ovvio. Insegno ai miei studenti a non utilizzare tali costrutti a meno che non ritengano che valga la pena dedicarvi un blocco di commenti, che descrive che si tratta di un errore intenzionale e perché questa soluzione è migliore delle alternative. Questo scoraggia l'uso sciatto, ma lo rende comunque consentito nei casi in cui viene utilizzato a vantaggio.

Questo è più o meno equivalente a quello che abbiamo fatto nei progetti spaziali quando qualcuno voleva violare lo standard di codifica: doveva chiedere la dispensa (e io sono stato chiamato a consigliare sulla sentenza).

Non mi piace che le mie switchaffermazioni falliscano: sono troppo soggette a errori e difficili da leggere. L'unica eccezione è quando più caseistruzioni fanno tutte esattamente la stessa cosa.

Se c'è del codice comune che più rami di un'istruzione switch vogliono usare, lo estraggo in una funzione comune separata che può essere chiamata in qualsiasi ramo.

In alcuni casi, utilizzare i fall-through è un atto di pigrizia da parte del programmatore: potrebbero utilizzare una serie di || istruzioni, ad esempio, ma invece utilizzare una serie di casi di switch "catch-all".

Detto questo, li ho trovati particolarmente utili quando so che alla fine avrò comunque bisogno delle opzioni (ad esempio in una risposta di menu), ma non ho ancora implementato tutte le scelte. Allo stesso modo, se stai facendo un fall-through sia per 'a' che per 'A', trovo sostanzialmente più pulito usare il fall-through dell'interruttore rispetto a un'istruzione if composta.

Probabilmente è una questione di stile e di come pensano i programmatori, ma generalmente non mi piace rimuovere i componenti di un linguaggio in nome della 'sicurezza' - motivo per cui tendo più al C e alle sue varianti / discendenti che, diciamo, Giava. Mi piace essere in grado di fare le scimmie con suggerimenti e simili, anche quando non ho "motivo" per farlo.

Il fall-through dovrebbe essere utilizzato solo quando viene utilizzato come tabella di salto in un blocco di codice. Se c'è una parte del codice con un'interruzione incondizionata prima di più casi, tutti i gruppi di casi dovrebbero terminare in questo modo.

Qualsiasi altra cosa è "cattiva".