Devrait instructions de commutation toujours contenir une clause de défaut?

Pas.

Que faire si il n'y a aucune action par défaut, le contexte a son importance. Que faire si vous n'en avez que pour agir sur quelques valeurs?

Prendre l'exemple de la lecture des combinaisons de touches pour un jeu

switch(a)
{
   case 'w':
     //Move Up
     break;
   case 's':
     //Move Down
     break;
   case 'a':
     //Move Left
     break;
   case 'd':
     //Move Right
     break;
}

Ajoutant:

default: //Do nothing

Est juste un gaspillage de temps et augmente la complexité du code pour aucune raison.

N'ayant PAS le cas par défaut peut être bénéfique dans certaines situations.

Si votre commutateur cas sont les énumérations, les valeurs, en n'ayant pas un cas de défaut, vous pouvez obtenir un message d'avertissement du compilateur si il vous manque l'un des cas. De cette façon, si de nouvelles valeurs enum sont ajoutés dans le futur et que vous oubliez d'ajouter des cas, pour ces valeurs dans le commutateur, vous pouvez vous renseigner sur le problème au moment de la compilation. Vous devriez toujours vous assurer que le code prend les mesures appropriées pour non gérée valeurs, dans le cas où une valeur non valide a été moulé pour le type enum. Donc, cela peut fonctionner mieux pour les cas simples où l'on peut revenir dans l'énumération de cas plutôt que de rompre.

enum SomeEnum
{
    ENUM_1,
    ENUM_2,
    //More ENUM values may be added in future
};

int foo(SomeEnum value)
{
    switch (value)
    {
    case ENUM_1:
        return 1;
    case ENUM_2:
        return 2;
    }
    //handle invalid values here
    return 0;
 }

Si une instruction "switch" toujours inclure une clause de défaut? Pas de. Il devrait généralement comprennent un défaut.

Y compris une clause de défaut n'a de sens que si il ya quelque chose pour elle de le faire, comme faire valoir une condition d'erreur ou de fournir un comportement par défaut. Y compris un "juste parce que" est-cargo culte de la programmation et ne fournit aucune valeur. C'est le "switch" équivalent de dire que tous les "si" états devraient inclure un "else".

Voici un exemple trivial d'où il n'a pas de sens:

void PrintSign(int i)
{
    switch (Math.Sign(i))
    {
    case 1:
        Console.Write("positive ");
        break;
    case -1:
        Console.Write("negative ");
        break;
    default: //useless
    }
    Console.Write("integer");
}

C'est l'équivalent de:

void PrintSign(int i)
{
    int sgn = Math.Sign(i);
    if (sgn == 1)
        Console.Write("positive ");
    else if (sgn == -1)
        Console.Write("negative ");
    else //also useless
    {
    }
    Console.Write("integer");
}

Avoir une clause de défaut quand il n'est pas vraiment nécessaire est Une programmation défensive
Cela conduit généralement à un code qui est trop complexe à cause de trop de code de gestion d'erreur.
Cette gestion d'erreur et le code de détection de nuit à la lisibilité du code, rend la maintenance plus difficile et conduit à terme à plus de bugs qu'elle n'en résout.

Donc je crois que si le défaut ne devrait pas être atteint - vous n'avez pas à les ajouter.

Note que "ne devrait pas être atteint" signifie que s'il atteint c'est un bug dans le logiciel vous avez besoin pour tester les valeurs qui peuvent contenir des valeurs indésirables en raison de la saisie de l'utilisateur, etc.

Si vous savez que l'instruction switch n'aurez jamais un strict défini des étiquettes ou les valeurs, il suffit de faire ce pour couvrir les bases, de cette façon, vous obtiendrez toujours valide résultat.. il suffit de mettre la valeur par défaut sur le label par programme/logiquement être le meilleur gestionnaire pour d'autres valeurs.

switch(ResponseValue)
{
    default:
    case No:
        return false;
    case Yes;
        return true;
}

Vous devriez avoir une valeur par défaut à attraper des nations unies-les valeurs attendues venir dans.

Cependant, je suis en désaccord avec le Adrian Smith que votre message d'erreur par défaut devrait être quelque chose de totalement dépourvue de sens. Il y a peut être un non-traitée cas où vous n'avez pas entrevoir (qui est un peu le but) que votre utilisateur peut voir et un message comme "inaccessible" est totalement inutile et n'aide pas n'importe qui dans cette situation.

Cas au point, combien de fois avez-vous eu un totalement dénuée de sens BSOD? Ou une exception fatale @ 0x352FBB3C32342?

C'est une option de codage de "convention". Selon l'usage est de savoir si ou non il est nécessaire. Personnellement, je crois que si vous n'en avez pas besoin, il ne devrait pas être là. Pourquoi inclure quelque chose qui ne sera pas utilisé, ou atteinte par l'utilisateur?

Si le cas les possibilités sont limitées (c'est à dire un Booléen), alors la clause de défaut est redondant!

Parce que MISRA C dit:

L'exigence pour une dernière clause de défaut est une programmation défensive. Cette clause est, soit de prendre les mesures appropriées ou qui contiennent un adapté commentaire pour expliquer pourquoi aucune action n'est prise.

Cela dit, je recommande contre MISRA C sur ce, pour la plupart des logiciels:

• Ce une programmation défensive guide de style ne se soucie pas de que seules certaines valeurs peuvent être valide – si la variable est physiquement capable de prendre de la valeur, même si ce serait un bug, vous êtes censé le gérer. La plupart des logiciels devrait préférez imprimer une trace de la pile au lieu de "manipulation" des bugs (comme mentionné par Ophir Yoktan).
• Enum interrupteurs, en particulier, devraient avoir aucune clause de défaut (comme Harlan Kassler dit). Et, comme Harlan éminemment démontre, à la manipulation des valeurs non valides peuvent être effectuées à l'extérieur de l'interrupteur – un point qui manquait dans Misra de discussion.

Dépend de la façon dont le commutateur en particulier la langue des œuvres, mais dans la plupart des langues en aucun cas appariés, l'exécution passe à travers l'instruction switch sans avertissement. Imaginez-vous prévu un certain ensemble de valeurs et de prises en charge dans le commutateur, cependant, vous obtenez une autre valeur dans l'entrée. Rien ne se passe et vous ne savez rien de ce qui s'est passé. Si vous avez attrapé le cas par défaut, vous le savez, il y a quelque chose de mal.

Je crois que c'est tout à fait spécifiques à la langue et pour le C++ cas un point mineur pour enum class type. Ce qui semble plus sûr que les traditionnels C enum. MAIS

Si vous regardez à la mise en œuvre de std::byte c'est quelque chose comme:

enum class byte : unsigned char {} ;

Source: https://en.cppreference.com/w/cpp/language/enum

Et aussi pensez à ceci:

Sinon, si T est un type d'énumération qui est soit l'étendue ou
non délimité fixes de type sous-jacent, et si l'embrassa-init-liste a
seulement un initialiseur, et si la conversion de l'initialiseur de
le type sous-jacent est non-rétrécissement, et si l'initialisation est
direct de la liste d'initialisation, puis l'énumération est initialisé avec
le résultat de la conversion de l'initialiseur de son type sous-jacent.

(depuis C++17)

Source: https://en.cppreference.com/w/cpp/language/list_initialization

Ceci est un exemple de l'enum de classe représentant les valeurs qui ne sont pas définis à l'énumérateur. Pour cette raison, vous ne pouvez pas placer une confiance totale dans les énumérations. Selon l'application, ce qui pourrait être important.

Cependant, j'aime vraiment ce que @Harlan Kassler a dit dans son post et va commencer à utiliser cette stratégie dans certaines situations de moi-même.

Juste un exemple dangereux enum class:

enum class Numbers : unsigned
{
    One = 1u,
    Two = 2u
};

int main()
{
    Numbers zero{ 0u };
    return 0;
}