Break sur le cas par défaut dans le commutateur

Je suis un peu perplexe quand ou non à inclure breakaprès le dernier cas, souvent default.

switch (type) {
    case 'product':

        // Do behavior

        break;
    default:

        // Do default behavior

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

breakJe crois comprendre que le seul but est d’empêcher le code de traverser le reste de la switchcasse.

Est-il alors considéré comme plus logique d’avoir un breakdernier pour des raisons de cohérence ou d’éviter de l’avoir du fait de son breaknon-utilisation fonctionnelle? Les deux sont logiques de différentes manières à mon avis.

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

breakn'est pas techniquement nécessaire après la dernière alternative (ce qui, notez-vous, ne doit pas l'être default: c'est parfaitement légal, et parfois même utile de mettre la defaultbranche en premier); Que votre code tombe à la fin de l' switchinstruction 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 un returnou break, pour trois raisons:

1. Refactorability. Si toutes vos branches se terminent par breakou return, vous pouvez les réorganiser sans en changer le sens. Cela rend moins probable qu'une telle réorganisation introduise une régression.
2. Cohérence et moindre surprise. La cohérence dit que vos branches doivent se terminer de manière cohérente, sauf si leur signification est réellement différente. Le principe de la moindre surprise veut que des choses similaires se ressemblent. La fin de la dernière branche d'un switchbloc exactement comme les précédentes remplit les deux, ce qui facilite la lecture et la compréhension. Si vous laissez de côté le contenu explicite break, la dernière branche sera optiquement différente (ce qui est particulièrement important pour une analyse rapide), et afin de voir que ce n'est pas vraiment différent, le lecteur doit descendre au niveau de la lecture des déclarations individuelles. .
3. Se protéger. Si vous prenez l'habitude de fermer toutes vos switchbranches avec un break, cela deviendra automatique au bout d'un moment et vous aurez moins de chances de l'oublier accidentellement là où ça compte. En vous entraînant à attendre la breakfin de chaque branche, vous pourrez également détecter les breakinstructions manquantes , ce qui est excellent pour le débogage et le dépannage.

Étant donné l’ambiguïté qui existe autour de l’utilisation de switch-casedans la plupart des langues, lors de son utilisation, je suggérerais de toujours utiliser une breakdéclaration, sauf si elle est explicitement et par définition non voulue .

Ceci est en partie dû au fait que chaque caseappel est identique, ce qui, à mon avis, améliorerait la lisibilité. Mais cela signifie aussi que si quelqu'un (même vous) choisit d'insérer un caseaprè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 bugs lors de l'ajout de nouveau code.

Il n'y a pas breaknécessaire après le dernier cas. J'utilise le mot " dernier " (pas par défaut ) car ce n'est pas nécessaire, par défaut le cas est le dernier.

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

default:
//do default work
break;

case 3:
//do stuff

}

Et nous savons, a 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 se réfèrent à mon code. Je peux choisir d'utiliser if(a), ce serait une question de mon choix