[解決済み] if ... elseのif構文をelse節で終了させるメリットは何ですか？

質問

私たちの組織では が必要です。 というコーディングルールを（何の説明もなく）作っています。

if ... else ifの構成はelse節で終了させるべきである。

例1:

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

例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 */
}

これはどのようなエッジケースに対応するように設計されているのでしょうか？

また、この理由で気になるのは 例1 は else が必要ですが 例2 はそうなっています。もし再利用性や拡張性が理由なら、私は else を使うべきだと思います。

どのように解決するのですか？

別の回答でも紹介しましたが、MISRA-Cのコーディングガイドラインからです。目的はディフェンシブ・プログラミングで、ミッションクリティカルなプログラミングでよく使われる概念です。

つまり、すべての if - else if で終わらなければなりません。 else でなければならず、すべての switch で終わらなければなりません。 default .

これには2つの理由があります。

• 自己文書化されたコード。もし、あなたが else を書きながらそれを空にすることは、次のことを意味します。 if でも else if は真である" 。

  を書かないのは else を書かないということは、次のことを意味します。 if でも else if が真であるか、それを考慮することを完全に忘れていて、私のコードのここに潜在的に太いバグがあります" 。

• 暴走するコードを止める。ミッションクリティカルなソフトウェアでは、非常に起こりにくいことまで考慮した、堅牢なプログラムを書く必要があります。そのため、次のようなコードを目にすることがあります。

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

  このコードは PC プログラマやコンピュータ科学者にとってはまったく異質なものですが、ミッションクリティカルなソフトウェアでは完全に意味をなします。なぜなら、何らかの理由で "mybool" が破損してしまった場合を捕捉するからです。

  歴史的には、EMI/ノイズのために RAM メモリが破損することを恐れていました。これは、今日ではあまり問題ではありません。メモリ破損が発生するのは、コードの他の場所のバグである可能性がはるかに高く、間違った場所へのポインタ、配列の境界外バグ、スタック オーバーフロー、コードの暴走などがあります。

  つまり、ほとんどの場合、このようなコードは、実装段階でバグを書いたときに、自分の顔を叩くために戻ってきます。つまり、バグを書いたときに、書いているプログラムが教えてくれるという、デバッグ技術としても使用できるのです。

EDIT

理由については else が必要ない理由について if :

または if-else は、変数が持ちうるすべての値を完全に網羅しています。しかし、単純な if-else if-else ステートメントは必ずしもすべての可能な値をカバーするためにあるわけではなく、もっと広い使い方があるのです。多くの場合、ある条件をチェックして、それが満たされなければ何もしない、というだけである。そうすると、防御的なプログラミングを記述して if のようなケースをカバーするために防御的なプログラミングを書くことは、単に意味がありません。

さらに、もしあなたが空の else の後に空の else .

MISRA-C:2012 15.7には、以下の理由についての根拠が示されていません。 if が不要であることの根拠を示さず、ただ述べている。

注意: 最後の else ステートメントは、単純な else ステートメントを使用します。