Changer de déclaration Fallthrough ... devrait-il être autorisé?

Question

Pour autant que je me souvienne, j'ai évité d'utiliser l'instruction switch fallthrough. En fait, je ne me souviens jamais d'entrer dans ma conscience comme un moyen possible de faire des choses qu'elle a été foré dans ma tête dès le début qu'il n'était rien de plus que d'un bug dans l'instruction switch. Cependant, aujourd'hui, j'ai couru à travers un code qui utilise par conception, qui m'a immédiatement demandais ce que tout le monde pense au sujet de l'instruction switch fallthrough.

Est-ce quelque chose qu'un langage de programmation devrait explicitement permettent pas (comme C#, mais il fournit une solution de contournement) ou est-ce une caractéristique d'une langue qui est assez puissant pour laisser au programmeur les mains?

Edit: Je n'étais pas assez précis de ce que je voulais dire par fallthrough. J'utilise ce type de beaucoup de choses:

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

Cependant, je suis préoccupé par quelque chose comme cela.

   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;
   }

De cette façon, chaque fois que le cas est 0, 1, il va tout faire dans l'instruction switch. J'ai vu cela en conception et je ne sais pas si je suis d'accord que les instructions de commutation doit être utilisé de cette façon. Je pense que le premier exemple de code est très utile et sûr. Le second semble sorte de dangereux.

Answer 1

Il peut dépendre de ce que vous considérez fallthrough. Je suis ok avec ce genre de chose:

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;
}

Mais si vous avez un cas étiquette suivi par le code qui passe à travers un autre cas, l'étiquette, j'avais à peu près toujours considérer que le mal. Peut-être le déplacement de la commune code d'une fonction et l'appel de ces deux pays serait une meilleure idée.

Et s'il vous plaît noter que j'utilise le Marshall Cline définition de "mal"

Answer 2

C'est une épée à deux tranchants. Parfois très utile, souvent dangereux.

Quand est-ce bon? Quand vous voulez que 10 cas soient traités de la même façon ...

 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;
}
 

La règle que j’aime bien est que si vous faites quelque chose d’extraordinaire où vous excluez la pause, vous avez besoin d’un commentaire clair / * FALLTHROUGH * / pour indiquer que telle était votre intention.

Answer 3

Avez-vous entendu parler de l'appareil de Duff ? C’est un excellent exemple d’utilisation de l’interrupteur en cascade.

C'est une fonctionnalité qui peut être utilisée et abusée, comme presque toutes les fonctionnalités linguistiques.

Answer 4

La chute est vraiment une chose pratique, selon ce que vous faites. Considérez ce moyen simple et compréhensible d’organiser les options:

 switch ($someoption) {
  case 'a':
  case 'b':
  case 'c':
    // do something
    break;
  case 'd':
  case 'e':
    // do something else
    break;
}
 

Imaginez cela avec if / else. Ce serait un gâchis.