Switchステートメントのフォールスルー…許可されるべきか？[閉まっている]

覚えている限り、switchステートメントのフォールスルーの使用は避けてきました。実際、switchステートメントのバグにすぎないということを、頭の中で掘り下げたため、可能なこととして意識の中に入るのを思い出すことはできません。しかし、今日、私はそれを仕様で使用するコードに出くわしました。そのため、コミュニティの誰もがswitchステートメントのフォールスルーについて何を考えているのかすぐに気になりました。

それはプログラミング言語が明示的に許可してはいけないものですか（C＃のように、回避策を提供します）、それともプログラマーの手に委ねるのに十分強力な言語の機能ですか？

編集： 私はフォールスルーで何を意味するのか十分に特定していませんでした。私はこのタイプをよく使います：

    switch(m_loadAnimSubCt){
        case 0:
        case 1:
            // Do something
            break;
        case 2:
        case 3:
        case 4:
            // Do something
            break;
   }

しかし、私はこのようなことが心配です。

   switch(m_loadAnimSubCt){
        case 0:
        case 1:
            // Do something, but fall through to the other cases
            // after doing it.

        case 2:
        case 3:
        case 4:
            // Do something else.
            break;
   }

このように、ケースが0、1の場合は常に、switchステートメントのすべてを実行します。これは仕様で見たことがありますが、switchステートメントをこのように使用する必要があることに同意するかどうかはわかりません。最初のコード例は非常に便利で安全だと思います。2番目は一種の危険なようです。

それはあなたがフォールスルーと考えるものに依存するかもしれません。私はこの種のもので大丈夫です：

switch (value)
{
  case 0:
    result = ZERO_DIGIT;
    break;

  case 1:
  case 3:
  case 5:
  case 7:
  case 9:
     result = ODD_DIGIT;
     break;

  case 2:
  case 4:
  case 6:
  case 8:
     result = EVEN_DIGIT;
     break;
}

しかし、ケースラベルに続いて別のケースラベルに分類されるコードがある場合、私はほとんど常にその悪を考慮します。おそらく、共通のコードを関数に移動し、両方の場所から呼び出すほうがよいでしょう。

また、「悪」のC ++ FAQ定義を使用していることに注意してください。

両刃の剣です。それは時々非常に便利ですが、しばしば危険です。

いつおいしい？10個のケースがすべて同じように処理されるようにしたい場合...

switch (c) {
  case 1:
  case 2:
            ... Do some of the work ...
            /* FALLTHROUGH */
  case 17:
            ... Do something ...
            break;
  case 5:
  case 43:
            ... Do something else ...
            break;
}

私が好きなルールの1つは、休憩を除外することで気の利いたことをする場合は、明確なコメント/ * FALLTHROUGH * /が必要であることを示しています。

ダフのデバイスをご存知ですか？これは、スイッチフォールスルーを使用する良い例です。

ほとんどすべての言語機能と同様に、これは使用できる機能であり、悪用される可能性があります。

フォールスルーは、何をしているのかに応じて、本当に便利なものです。オプションを整理するためのこのきちんとした理解できる方法を検討してください：

switch ($someoption) {
  case 'a':
  case 'b':
  case 'c':
    // Do something
    break;

  case 'd':
  case 'e':
    // Do something else
    break;
}

if / elseでこれを行うことを想像してください。混乱するでしょう。

これは非常に便利な場合もありますが、通常、フォールスルーが目的の動作になることはありません。フォールスルーは許可されるべきですが、暗黙的ではありません。

一部のデータの古いバージョンを更新する例：

switch (version) {
    case 1:
        // Update some stuff
    case 2:
        // Update more stuff
    case 3:
        // Update even more stuff
    case 4:
        // And so on
}

スイッチのフォールバックの別の構文が好きです。

switch(myParam)
{
  case 0 or 1 or 2:
    // Do something;
    break;
  case 3 or 4:
    // Do something else;
    break;
}

注：フラグを使用して列挙型のすべてのケースを宣言する場合、これは列挙型ですでに可能です。それもそれほど悪く聞こえません。ケースはすでにあなたの列挙型の一部である可能性があります（すべきですか？）。

たぶん、これは拡張メソッドを使用する流暢なインターフェースの良い例です（しゃれは意図されていません）。えっと…

int value = 10;
value.Switch()
  .Case(() => { /* Do something; */ }, new {0, 1, 2})
  .Case(() => { /* Do something else */ } new {3, 4})
  .Default(() => { /* Do the default case; */ });

それはおそらくもっと読みにくいですが：P

何でもそうです：注意して使用すると、エレガントなツールになります。

しかし、欠点はそれを使用しないことを正当化すること、そして最後にそれをもう許可しないこと（C＃）よりも多いと思います。問題の中には：

• 休憩を「忘れる」のは簡単です
• コードメンテナーにとって、省略された改行が意図的なものであることは必ずしも明白ではありません

スイッチ/ケースのフォールスルーの活用：

switch (x)
{
case 1:
case 2:
case 3:
 Do something
 break;
}

スイッチ/ケースのフォールスルーのBaaaaadの使用：

switch (x)
{
case 1:
    Some code
case 2:
    Some more code
case 3:
    Even more code
    break;
}

これは、私の見解では、損失のないif / else構文を使用して書き換えることができます。

私の最後の言葉：このスタイルが使用され、よく理解されているレガシーコードを維持しているのでない限り、悪い例のようにフォールスルーケースラベルに近づかないでください。

それは強力で危険です。フォールスルーの最大の問題は、明示的ではないことです。たとえば、フォールスルーのあるスイッチを持つ頻繁に編集されるコードに遭遇した場合、それが意図的なものであり、バグではないことをどのようにして知るのでしょうか。

私がそれを使用するときはいつでも、適切にコメントされていることを確認します。

switch($var) {
    case 'first':
        // Fall-through
    case 'second':
        i++;
        break;
 }

最初の例のようにフォールスルーを使用することは明らかにOKであり、実際のフォールスルーとは見なしません。

2番目の例は危険であり、（広範囲にコメントされていない場合）自明ではありません。私はこのような構築物を使用しないように私の学生を教えていない限りコメントブロックを捧げる努力をする価値があると考え、これは、これが意図的なフォールスルーであり、このソリューションが他の方法より優れている理由を説明しています。これはずさんな使用を思いとどまらせますが、それが有利に使用される場合でもそれを許可します。

これは、だれかがコーディング標準に違反することを望んだときに宇宙プロジェクトで行ったのとほぼ同じです。彼らは、認可を申請しなければなりませんでした（そして、裁定について助言を求められました）。

自分のswitch発言が失敗するのは好きではありません。エラーが発生しやすく、読みにくいです。唯一の例外は、複数のcaseステートメントがすべて正確に実行される場合です。同じことをです。

switchステートメントの複数のブランチで使用したい共通コードがある場合は、それを任意のブランチで呼び出すことができる個別の共通関数に抽出します。

場合によっては、フォールスルーの使用は、プログラマー側の怠惰な行為です。一連の||を使用できます。ステートメントなどですが、代わりに一連の「キャッチオール」スイッチケースを使用します。

そうは言っても、結局それがわかっているときは特に役立つことがわかりました私は（メニュー応答、例えば）とにかくオプションを必要とするつもりですが、まだすべての選択肢を実装していません。同様に、「a」と「A」の両方でフォールスルーを実行している場合、複合ifステートメントよりもスイッチフォールスルーを使用する方がはるかにクリーンです。

それはおそらくスタイルとプログラマーの考え方の問題ですが、私は一般に「安全」の名のもとに言語のコンポーネントを削除するのが好きではありません。 Java。「理由」がないときでも、ポインタなどでモンキーアラウンドができるのが好きです。

フォールスルーは、コードブロックへのジャンプテーブルとして使用する場合にのみ使用してください。より多くのケースの前に無条件のブレークがあるコードの部分がある場合、すべてのケースグループはそのように終了する必要があります。

それ以外は「悪」です。