Quel est l’avantage de mettre fin à l’instruction if... else if construit avec une clause else ?

Question

Notre organisation dispose d'un nécessaire de codage de la règle (sans aucune explication):

si ... sinon si des constructions doit être terminé par une clause else

Exemple 1:

if ( x < 0 )
{
   x = 0;
} /* else not needed */

Exemple 2:

if ( x < 0 )
{
    x = 0;
}
else if ( y < 0 )
{
    x = 3;
}
else    /* this else clause is required, even if the */
{       /* programmer expects this will never be reached */
        /* no change in value of x */
}

Ce cas limite est-elle conçue pour gérer?

Ce qui me préoccupe aussi sur la raison en est que l'Exemple 1 n'a pas besoin d' else mais l'Exemple 2 . Si la raison en est ré-utilisabilité et de l'extensibilité, je pense que else doit être utilisé dans les deux cas.

Answer 1

Comme mentionné dans une autre réponse, c'est de la MISRA-C des directives de codage. Le but est une programmation défensive, un concept qui est souvent utilisé dans la mission-critique la programmation.

C'est, chaque if - else if doit se terminer par un else, et chaque switch doit se terminer par un default.

Il y a deux raisons à cela:

• L'auto-documentation du code. Si vous écrivez un else mais le laisser vide, cela signifie: "je n'ai aucun doute considéré comme le scénario quand ni if ni else if sont vraies".

  Ne pas écrire un else "signifie: "j'ai considéré le scénario où ni if ni else if sont vraies, ou j'ai complètement oublié de prendre en considération et il y a potentiellement un gros bug ici, dans mon code".

• Arrêter l'emballement de code. Critiques de logiciels, vous devez écrire à de solides programmes qui compte, même pour le très peu probable. Ainsi, vous pouvez voir le code comme

  if (mybool == TRUE) 
  {
  } 
  else if (mybool == FALSE) 
  {
  }
  else
  {
    // handle error
  }
  

  Ce code sera complètement étranger à PC programmeurs et informaticiens, mais il est parfaitement logique dans la mission-logiciels critiques, parce qu'il attrape le cas où le "mybool" a disparu corrompus, pour quelque raison que ce soit.

  Historiquement, tu aurais peur de corruption de la mémoire RAM à cause de EMI/bruit. Ce n'est pas vraiment un problème aujourd'hui. Beaucoup plus probable, de corruption de mémoire se produit en raison de bugs ailleurs dans le code: les pointeurs à de mauvais endroits, array-hors-limites des bugs, de débordement de pile, l'emballement de code etc.

  Donc la plupart du temps, le code comme ceci revient à claque de vous-même dans le visage quand vous avez écrit bugs lors de la phase de mise en œuvre. Le sens qu'il pourrait également être utilisé comme un debug technique: le programme que vous écrivez vous dit quand vous avez écrit bugs.

---

MODIFIER

Concernant les raisons de else n'est pas nécessaire après chaque if:

Un if-else ou if-else if-else complètement couvre toutes les valeurs possibles d'une variable peut avoir. Mais un simple if déclaration n'est pas forcément là pour couvrir toutes les valeurs possibles, il est beaucoup plus large utilisation. Le plus souvent, vous voulez simplement vérifier une certaine condition, et si elle n'est pas remplie, alors ne rien faire. Alors il est tout simplement pas de sens d'écrire une programmation défensive pour couvrir l' else des cas.

De Plus il serait encombrer le code complètement si vous avez écrit un vide else après chaque if.

MISRA-C:2012 15.7 donne aucune raison pourquoi else n'est pas nécessaire, il vient d'états:

Remarque: un final else déclaration n'est pas requise pour un simple if l'énoncé.

Answer 2

Votre entreprise suivie de codage MISRA d'orientation. Il y a quelques versions de ces lignes directrices qui contiennent cette règle, mais à partir de MISRA-C:2004^†:

La règle 14.10 (obligatoire): Tous les if ... else si les constructions doivent être résilié avec une clause else.

Cette règle s'applique chaque fois qu'une instruction if est suivie par un ou plusieurs sinon si annuels; le dernier else if doit être suivi par un else l'énoncé. Dans le cas d'un simple if énoncé de l' else la déclaration n'a pas besoin d'être inclus. L'exigence d'un final else la déclaration est une programmation défensive. L' else déclaration ne soit prendre des mesures appropriées ou qui contiennent un adapté commentaire pourquoi pas des mesures sont prises. Ceci est cohérent avec l'obligation d'avoir une final default clause dans un switch déclaration. Par exemple ce code est simple si la déclaration:

if ( x < 0 )
{
 log_error(3);
 x = 0;
} /* else not needed */

alors que le code suivant montre un if, else if construire

if ( x < 0 )
{
 log_error(3);
 x = 0;
}
else if ( y < 0 )
{
 x = 3;
}
else /* this else clause is required, even if the */
{ /* programmer expects this will never be reached */
 /* no change in value of x */
}

Dans MISRA-C:2012, qui annule et remplace la version de 2004 et la recommandation actuelle pour les nouveaux projets, la même règle existe, mais est numéroté 15.7.

Exemple 1: en une seule instruction si le programmeur de vérifier les n certain nombre de conditions et effectue une seule opération.

if(condition_1 || condition_2 || ... condition_n)
{
   //operation_1
}

Dans une utilisation régulière de l'exécution d'une opération n'est pas nécessaire tout le temps quand if est utilisé.

Exemple 2: Ici programmeur contrôles n certain nombre de conditions et d'effectuer de multiples opérations. En utilisation régulière if..else if , c'est comme switch vous devrez peut-être effectuer une telle opération par défaut. Ainsi, l'utilisation else est nécessaire comme par misra standard

if(condition_1 || condition_2 || ... condition_n)
{
   //operation_1
}
else if(condition_1 || condition_2 || ... condition_n)
{
  //operation_2
}
....
else
{
   //default cause
}

---

^† Actuelles et les dernières versions de ces publications sont disponibles à l'achat via le MISRA boutique en ligne (via).

Answer 3

<blockquote> <p>C’est l’équivalent d’exiger un cas par défaut dans chaque commutateur.</p> <p><strong>Ce supplément d’autre diminuera de <a href="https://en.wikipedia.org/wiki/Code_coverage">couverture du code</a> de votre programme.</strong></p><hr><p>D’après mon expérience avec le portage du noyau linux, ou code android à autre plateforme plusieurs fois nous avons fait quelque chose de mal et dans logcat, nous voyons une erreur comme</p><pre><code></code></pre></blockquote>

Answer 4

Seule une brève explication, car j'ai fait cela tous les il y a 5 ans.

Il est (avec la plupart des langues) n syntaxiques obligation d'inclure "null" else (et inutiles {..}), et dans "de simples petits programmes" il n'est pas nécessaire. Mais les programmeurs ne pas écrire "de simples petits programmes", et, tout aussi important, ils n'ont pas d'écrire des programmes qui sera utilisé à la fois.

Quand on écrire un if/else:

if(something)
  doSomething;
else
  doSomethingElse;

cela semble simple et on ne voit même le point de l'ajout d' {..}.

Mais un jour, quelques mois à partir de maintenant, un autre programmeur (vous ne pourrait jamais faire une telle erreur!) aurez besoin pour "améliorer" le programme et ajouter un énoncé.

if(something)
  doSomething;
else
  doSomethingIForgot;
  doSomethingElse;

Soudain, doSomethingElse un peu oublie qu'il est censé être dans l' else de la jambe.

Donc, vous êtes un bon petit programmeur et que vous utilisez toujours {..}. Mais vous écrivez:

if(something) {
  if(anotherThing) {
    doSomething;
  }
}

Tout est bien et bon jusqu'à ce que le petit nouveau fait de minuit modification:

if(something) {
  if(!notMyThing) {
  if(anotherThing) {
    doSomething;
  }
  else {
    dontDoAnything;  // Because it's not my thing.
  }}
}

Oui, c'est mal formaté, mais c'est la moitié du code dans le projet, et les "auto formateur" obtient bollixed par tous les #ifdef des déclarations. Et, bien sûr, le code est beaucoup plus compliqué que ce jouet exemple.

Malheureusement (ou pas), j'ai été de ce genre de chose depuis quelques années maintenant, donc je n'ai pas de frais "réels" par exemple dans l'esprit-le ci-dessus est (évidemment) artificiel et un peu à l'eau de rose.

Answer 5

Ceci, est fait pour rendre le code plus lisible, pour Références ultérieures et de dire clairement, à un critique plus tard, que le reste des cas traités par le dernier `` , sont des cas de ne rien faire , pour qu’ils ne sont pas négligés en quelque sorte à première vue.

Il s’agit d’une bonne pratique de programmation, qui rend le code réutilisable et étendre-able.