web-dev-qa-db-fra.com

Interruption du cas par défaut dans le commutateur

Je suis un peu perplexe quand ou non pour inclure break après le dernier cas, souvent default.

switch (type) {
    case 'product':

        // Do behavior

        break;
    default:

        // Do default behavior

        break; // Is it considered to be needed?
}

breakseul but est, à mon avis, d'empêcher le code de s'exécuter dans le reste du cas switch-.

Est-il alors considéré comme plus logique d'avoir un break en dernier lieu en raison de la cohérence ou de ne pas l'avoir en raison du break n'appliquant aucune utilisation fonctionnelle? Les deux sont logiques de différentes manières à mon avis.

Cela pourrait dans une certaine mesure être comparé à la fin d'un .php fichier avec ?>. Je ne finis jamais avec ?> principalement en raison du risque de sortie d'espaces vides, mais on pourrait dire que ce serait la chose logique de terminer le fichier.

programming-practicesswitch-statement
91
Robin Castlin

break n'est pas techniquement nécessaire après la dernière alternative (ce qui, vous le savez, n'a pas à être default: c'est parfaitement légal, et parfois même utile de mettre le default branche en premier); si votre code passe par la fin de l'instruction switch ou breaks à la fin de sa dernière branche a le même résultat.

Cependant, je terminerais toujours chaque branche, y compris la dernière, par une instruction return ou break, pour trois raisons:

  1. Refactorabilité. Si toutes vos branches se terminent par break ou return, vous pouvez les réorganiser sans en changer la signification. Il est donc moins probable qu'une telle réorganisation introduise une régression.
  2. Cohérence et moindre surprise. La cohérence indique que vos branches doivent se terminer de manière cohérente, à moins qu'elles ne soient réellement différentes dans leur sens. Le principe de la moindre surprise dicte que des choses similaires doivent se ressembler. Terminer la dernière branche d'un bloc switch exactement comme les précédents remplit les deux, ce qui facilite la lecture et la compréhension. Si vous omettez le break explicite, la dernière branche sera optiquement différente (ce qui est particulièrement important pour un balayage rapide), et afin de voir que ce n'est vraiment pas différent, le lecteur doit descendre au début. niveau granuleux de la lecture des déclarations individuelles.
  3. Protégez-vous. Si vous prenez l'habitude de terminer toutes vos branches switch par un break, cela deviendra automatique après un certain temps, et vous serez moins susceptible de l'oublier accidentellement là où cela compte. Vous entraîner à attendre le break à la fin de chaque branche permet également de détecter les instructions break manquantes, ce qui est idéal pour le débogage et le dépannage.
147
tdammers

Étant donné l'ambiguïté qui existe autour de l'utilisation de switch-case dans la plupart des langues, lors de son utilisation je suggère de toujours utiliser une instruction break, sauf lorsqu'elle est explicite et par conception non souhaitée.

Cela est en partie dû au fait que chaque appel case se ressemble, ce qui, à mon avis, améliorerait la lisibilité. Mais cela signifie également que si quelqu'un (même vous) choisit d'insérer un case après le dernier à un stade ultérieur, il n'a pas besoin de se préoccuper de vérifier le bloc précédent, ce qui pourrait aider à réduire les bogues lors de l'ajout nouveau code.

12
user69037

Aucun break n'est nécessaire après le cas last. J'utilise le mot "dernier" (pas par défaut) car il n'est pas nécessaire que le cas par défaut soit le dernier cas.

switch(x)
{
case 1:
//do stuff
break;

default:
//do default work
break;

case 3:
//do stuff

}

Et nous savons, un break est nécessaire entre deux cases consécutifs. Parfois, j'utilise if(a!=0) dans mon code pour plus de lisibilité lorsque d'autres référent mon code. Je peux choisir d'utiliser if(a), ce serait une question de mon choix

1
Suvarna Pattayil