Est-il nécessaire d'ajouter le cas par défaut lors de l'utilisation de cas de commutateur?

Lors d'une récente révision du code, on m'a demandé de placer des defaultcas dans tous les fichiers, quel que soit le switchbloc utilisé, même s'il n'y a rien à faire default. Cela signifie que je dois mettre le defaultcas et ne rien écrire dedans.

Est-ce la bonne chose à faire? A quoi cela servirait-il?

Il semble qu'il y ait trois cas où une defaultdéclaration n'est pas nécessaire:

1. aucun autre cas n'est laissé, car il y a un ensemble limité de valeurs qui entrent dans le fichier switch case. Mais cela pourrait changer avec le temps (intentionnellement ou accidentellement), et il serait bon d’avoir un default caseéventuel changement, vous pouvez enregistrer ou avertir l’utilisateur d’une valeur erronée.

2. vous savez comment et où le switch casesera utilisé et quelles valeurs le saisiront. Là encore, cela pourrait changer et un traitement supplémentaire pourrait être nécessaire.

3. les autres cas ne nécessitent aucun traitement spécial. Si tel est le cas, je pense que vous êtes invité à ajouter un default case, car il s'agit d'un style de codage accepté, ce qui rend votre code plus lisible.

Les deux premiers cas sont basés sur des hypothèses. Donc (en supposant que vous travailliez dans une équipe pas si petite puisque vous avez des revues de code régulières), vous ne pouvez pas vous permettre de faire ces hypothèses. Vous ne savez pas qui travaillera avec votre code ou effectuera des appels à des fonctions / invoquant des méthodes dans votre code. De même, vous devrez peut-être utiliser le code de quelqu'un d'autre. Le même style de codage facilitera la gestion du code de quelqu'un (y compris votre code).

Est-ce le bon thiong à faire? A quoi cela servirait-il?

Il n'est pas rare que les normes de codage des entreprises exigent un cas par défaut pour toutes les switchinstructions. L’une des raisons est qu’il est facile pour les lecteurs de trouver la fin du texte switch. Une autre raison, probablement meilleure, est que cela vous fait réfléchir une seconde sur ce que votre code devrait faire lorsque la condition ne correspond pas à vos attentes. Quelle que soit la raison de l'exigence, s'il s'agit d'une norme de l'entreprise, vous devez la respecter sauf s'il existe une raison étanche à l'air.

Si vous pensez que votre switchcas inclut toutes les conditions possibles, alors une bonne chose à faire est de placer une assertdéclaration dans le cas par défaut. Ainsi, lorsque quelqu'un modifie le code et ajoute par inadvertance une condition que vous switchne couvrez pas, il remplit la assertfenêtre et réalise qu'il doit traiter cette partie du code.

Si vous switchne couvrez que quelques-unes des conditions possibles, mais que rien n'est spécial, vous pouvez laisser le cas par défaut vide. C'est une bonne idée d'ajouter un commentaire dans ce cas pour indiquer que le cas par défaut est intentionnellement vide, car les conditions qui le remplissent ne nécessitent aucun travail.

Si vous "basculez" sur un type d'énumération pur, il est dangereux d'avoir un repli par défaut. Lorsque vous ajouterez ultérieurement des valeurs au type énumération, le compilateur mettra en surbrillance les commutateurs avec les nouvelles valeurs non couvertes. Si vous avez la clause default ici, le compilateur restera silencieux et vous risquez de le manquer.

À bien des égards, cette question est la même que celle souvent posée Ai-je besoin d'une elseclause à la fin d'un if/ else ifladder couvrant toutes les options ?

La réponse est, syntaxiquement, non. Mais il y a cependant ...

Une defaultclause peut être là pour (au moins) deux raisons:

1. En tant que gestionnaire d'erreur - bien sûr, ne devrait jamais arriver ici! est une revendication qui peut être faite, mais que faire si elle fait? La corruption des données, ou pire encore, l'absence de validation des données sont des voies d'échec du programme si elles ne sont pas piégées correctement Dans ce cas, ce ne devrait pas être une clause vide!
2. Couverture de conception / code - même sous la forme la plus simple d'un organigramme, il existe deux routes à partir d'une instruction if et toujours otherwised'une casse. Il n'y a aucune raison de ne pas les inclure dans le code source.

Ma philosophie est toujours très simple: évaluez le pire scénario des deux options et optez pour le plus sûr. Dans le cas d'un vide elseou d'une defaultclause, les options les plus défavorables sont:

• Incluez-les: Trois ou quatre lignes supplémentaires de code "redondant".
• Ne les incluez pas: des données non fiables ou une condition inattendue ne sont pas interceptées, ce qui peut entraîner une défaillance du programme.

Overdramatic? Peut-être… mais mon logiciel risque alors de tuer des gens s'il échoue. Je préfère ne pas prendre ce risque.

De plus, les directives de la MISRA-C {voir le profil d’affiliation} recommandent une defaultclause pour chaqueswitch

Java ne vous oblige pas à avoir une instruction 'default', mais c'est une bonne pratique d'en avoir une tout le temps, même si le code ne peut jamais être atteint (maintenant). Voici quelques raisons:

En ayant une clause default inaccessible, vous montrez au lecteur de votre code que vous avez considéré les valeurs et que vous savez ce que vous faites. Vous autorisez également les modifications futures, par exemple, par exemple: une nouvelle valeur enum est ajoutée, le commutateur ne doit pas ignorer la nouvelle valeur en mode silencieux; vous pouvez lancer une exception à la place ou faire autre chose.

Pour capturer une valeur inattendue (au cas où vous n'activez pas une énumération) qui est transmise - elle peut être supérieure ou inférieure à celle attendue, par exemple.

Pour gérer les actions "par défaut" - où les commutateurs ont un comportement spécial. Par exemple, une variable peut être déclarée en dehors du commutateur mais pas initialisée et chaque cas l'initialise à quelque chose de différent. Default dans ce cas pourrait l'initialiser à une valeur par défaut afin que le code immédiatement après le commutateur ne commette pas d'erreur / génère une exception.

Même si vous décidez de ne rien mettre dans la valeur par défaut (pas d'exceptions, de journalisation, etc.), même un commentaire indiquant que vous avez pris en compte le fait que la défaillance ne se produira jamais peut améliorer la lisibilité de votre code; mais cela dépend de la préférence personnelle.

J'ajouterais également que cela dépend de la philosophie de la langue que vous utilisez. Dans Erlang, par exemple, où il est courant de «laisser tomber», vous ne définissez pas de cas par défaut, mais laissez votre casedéclaration en erreur si une situation non résolue se produit.

Vous devriez toujours avoir un défaut sauf si vous avez couvert de manière prouvable et permanente tous les cas. Cela ne coûte rien, et c'est une assurance contre le non-maintien de votre relevé de commutateur dans un programme en évolution.

Si vous êtes vraiment sûr que vous ne vous souciez pas d'autres cas, la valeur par défaut: break; // ne vous souciez pas, mais la valeur par défaut devrait ressembler à celle par défaut: throw new Error ("valeur inattendue");

De même, vous ne devriez jamais "passer à travers" une construction de cas non triviale sans ajouter de commentaire à l'effet que vous avez l'intention de faire passer. Java s'est trompé lors de la conception.

Considérer

enum Gender
{
       MALE ,
       FEMALE ;
}

et

void run ( Gender g )
{
      switch ( g )
      {
           case MALE :
                 // code related to males
                 break ;
           default :
                 assert Gender . FEMALE . equals ( g ) ;
                 // code related to females
                 break ;
      }
}

Je dirais que c'est mieux que d'avoir un cas MALE, un cas FEMALE et un cas par défaut qui lève une exception.

Pendant votre phase de test, l’ordinateur vérifiera si g est FEMALE. Pendant la production, le contrôle sera omis. (Ouais une microoptimisation!)

Plus important encore, vous maintiendrez votre objectif de couverture de code à 100%. Si vous écriviez un cas par défaut qui lève une exception, comment le testeriez-vous?