「goto」ブードゥー教を避ける？

switchいくつかのケースを処理する構造があります。switch動作enumを組み合わせた値によって重複したコードの問題を提起しています：

// All possible combinations of One - Eight.
public enum ExampleEnum {
    One,
    Two, TwoOne,
    Three, ThreeOne, ThreeTwo, ThreeOneTwo,
    Four, FourOne, FourTwo, FourThree, FourOneTwo, FourOneThree,
          FourTwoThree, FourOneTwoThree
    // ETC.
}

現在、switch構造は各値を個別に処理します。

// All possible combinations of One - Eight.
switch (enumValue) {
    case One: DrawOne; break;
    case Two: DrawTwo; break;
    case TwoOne:
        DrawOne;
        DrawTwo;
        break;
     case Three: DrawThree; break;
     ...
}

そこにアイデアがあります。私は現在、これをスタックif構造に分割して、代わりに単一行での組み合わせを処理しています：

// All possible combinations of One - Eight.
if (One || TwoOne || ThreeOne || ThreeOneTwo)
    DrawOne;
if (Two || TwoOne || ThreeTwo || ThreeOneTwo)
    DrawTwo;
if (Three || ThreeOne || ThreeTwo || ThreeOneTwo)
    DrawThree;

これは非常に長い論理評価の問題を引き起こし、読みにくく、維持するのが困難です。これをリファクタリングした後、私は代替案について考え始めswitch、ケース間のフォールスルーを伴う構造のアイデアを考え始めました。

フォールスルーを許可しないためgoto、その場合はaを使用する必要がありますC#。ただし、switch構造内でジャンプしても、信じられないほど長いロジックチェーンを防止し、コードの重複をもたらします。

switch (enumVal) {
    case ThreeOneTwo: DrawThree; goto case TwoOne;
    case ThreeTwo: DrawThree; goto case Two;
    case ThreeOne: DrawThree; goto default;
    case TwoOne: DrawTwo; goto default;
    case Two: DrawTwo; break;
    default: DrawOne; break;
}

これはまだ十分にクリーンなソリューションではなく、goto回避したいキーワードに関連したスティグマがあります。これをきれいにするもっと良い方法が必要だと思います。

私の質問

読みやすさと保守性に影響を与えずにこの特定のケースを処理するより良い方法はありますか？

gotoステートメントではコードが読みにくいと思います。構造をenum変えることをお勧めします。たとえばenum、各ビットが選択肢の1つを表すビットフィールドの場合、次のようになります。

[Flags]
public enum ExampleEnum {
    One = 0b0001,
    Two = 0b0010,
    Three = 0b0100
};

Flags属性は、重複しない値を設定していることをコンパイラーに伝えます。このコードを呼び出すコードは、適切なビットを設定できます。次に、このようなことをして、何が起こっているかを明確にすることができます。

if (myEnum.HasFlag(ExampleEnum.One))
{
    CallOne();
}
if (myEnum.HasFlag(ExampleEnum.Two))
{
    CallTwo();
}
if (myEnum.HasFlag(ExampleEnum.Three))
{
    CallThree();
}

これには、myEnumビットフィールドを適切に設定し、フラグ属性でマークするようにセットアップするコードが必要です。しかし、あなたの例の列挙型の値を次のように変更することでそれを行うことができます。

[Flags]
public enum ExampleEnum {
    One = 0b0001,
    Two = 0b0010,
    Three = 0b0100,
    OneAndTwo = One | Two,
    OneAndThree = One | Three,
    TwoAndThree = Two | Three
};

フォーム0bxxxxに数字を書くとき、それをバイナリで指定しています。したがって、ビット1、2、または3を設定していることがわかります（まあ、技術的には0、1、または2ですが、あなたは考えを知っています）。組み合わせが頻繁に一緒に設定される可能性がある場合は、ビットごとのORを使用して組み合わせに名前を付けることもできます。

IMOの問題の根本は、このコードが存在すらしてはならないということです。

明らかに、3つの独立した条件と、それらの条件が真である場合に行う3つの独立したアクションがあります。では、なぜそれらすべてが何をすべきか（列挙に難読化するかどうか）を伝えるために3つのブールフラグを必要とする1つのコードに集中し、次に3つの独立したことを組み合わせますか？単一の責任原則は、ここで休みを取っているようです。

属する3つの関数（つまり、アクションを実行する必要があることがわかった場所）への呼び出しを行い、これらの例のコードをごみ箱に委託します。

3つではなく10のフラグとアクションがあった場合、この種類のコードを拡張して1024の異なる組み合わせを処理しますか？私は望んでいない！1024が多すぎる場合、同じ理由で8も多すぎます。

gotoを使用しないことは、コンピューターサイエンスの「子供たちへの嘘」の概念の1つです。99％の確率で正しいアドバイスが得られますが、それほど珍しくなく特殊なものでもないので、新しいコーダーに「使用しない」と説明した方がはるかに優れています。

それで、いつそれらを使うべきですか？いくつかのシナリオがありますが、ヒットしていると思われる基本的なシナリオは、ステートマシンをコーディングするときです。ステートマシンよりもアルゴリズムの体系的で構造化された表現が優れていない場合、コード内のその自然な表現には非構造化ブランチが含まれ、おそらく構造を構築しないものについてできることは多くありませんステートマシン自体が少なくなるのではなく、より不明瞭になります。

コンパイラの作家はLALRパーサを実装するほとんどのコンパイラのソースコードが理由である、このことを知っている^* GOTOSが含まれています。ただし、実際に独自の字句解析器および構文解析器をコーディングする人はほとんどいません。

^{*-IIRCでは、ジャンプテーブルやその他の非構造化制御ステートメントを使用せずに、完全に再帰下降するLALL文法を実装することができます。したがって、本当にアンチゴートなら、これは1つの方法です。}

次の質問は、「この例はそれらのケースの1つですか？」です。

私が見ているのは、現在の状態の処理に応じて、次の3つの異なる可能な状態があるということです。それらの1つ（「デフォルト」）は単なるコード行であるため、技術的には、該当する状態の最後にそのコード行を追加することで、それを取り除くことができます。それにより、次の2つの状態に進むことができます。

残りの1つ（「3つ」）は、私が見ることができる1つの場所からのみ分岐しています。したがって、同じ方法で取り除くことができます。次のようなコードになります。

switch (exampleValue) {
    case OneAndTwo: i += 3 break;
    case OneAndThree: i += 4 break;
    case Two: i += 2 break;
    case TwoAndThree: i += 5 break;
    case Three: i += 3 break;
    default: i++ break;
}

ただし、これはあなたが提供したおもちゃの例です。「デフォルト」に重要なコードが含まれる場合、「3」が複数の状態から移行されるか、（最も重要なことですが）さらなる保守により状態が追加または複雑になる可能性が高い場合、正直に言って良いでしょうgotoを使用します（そして、何らかの理由でそれを維持する必要のある正当な理由がない限り、物事のステートマシンの性質を隠すenum-case構造を取り除きます）。

最良の答えは、ポリモーフィズムを使用することです。

IMOがifをより明確にし、間違いなく短くする別の答え：

if (One || OneAndTwo || OneAndThree)
  CallOne();
if (Two || OneAndTwo || TwoAndThree)
  CallTwo();
if (Three || OneAndThree || TwoAndThree)
  CallThree();

goto おそらくここで私の58番目の選択です...

これはなぜですか：

public enum ExampleEnum {
    One = 0, // Why not?
    OneAndTwo,
    OneAndThree,
    Two,
    TwoAndThree,
    Three
}
int[] COUNTS = { 1, 3, 4, 2, 5, 3 }; // Whatever

int ComputeExampleValue(int i, ExampleEnum exampleValue) {
    return i + COUNTS[(int)exampleValue];
}

OK、私は同意します、これはハックです（私はC＃開発者ではないので、コードを失礼します）が、効率の観点からこれは必須ですか？配列インデックスとして列挙型を使用することは有効なC＃です。

フラグを使用できない、または使用したくない場合は、末尾再帰関数を使用します。64ビットリリースモードでは、コンパイラはgotoステートメントに非常によく似たコードを生成します。対処する必要はありません。

int ComputeExampleValue(int i, ExampleEnum exampleValue) {
    switch (exampleValue) {
        case One: return i + 1;
        case OneAndTwo: return ComputeExampleValue(i + 2, ExampleEnum.One);
        case OneAndThree: return ComputeExampleValue(i + 3, ExampleEnum.One);
        case Two: return i + 2;
        case TwoAndThree: return ComputeExampleValue(i + 2, ExampleEnum.Three);
        case Three: return i + 3;
   }
}

受け入れられた解決策は問題なく、問題に対する具体的な解決策です。ただし、別のより抽象的なソリューションを提案したいと思います。

私の経験では、ロジックのフローを定義するために列挙型を使用することは、多くの場合、クラス設計が不十分であることの兆候であるため、コード臭です。

昨年私が取り組んだコードでこれが起こっているという実世界の例に出会いました。元の開発者は、インポートとエクスポートの両方のロジックを実行する単一のクラスを作成し、列挙型に基づいて2つのクラスを切り替えました。これで、コードは似ており、重複するコードがいくつかありましたが、コードが非常に読みにくく、テストが事実上不可能になるほど十分に異なっていました。最終的にそれを2つの別々のクラスにリファクタリングしました。これにより、両方が単純化され、実際に報告されていない多くのバグを見つけて排除することができました。

繰り返しになりますが、列挙型を使用してロジックのフローを制御することは、多くの場合設計上の問題であると述べなければなりません。一般的な場合、列挙型は主に、可能な値が明確に定義されているタイプセーフで消費者に優しい値を提供するために使用する必要があります。ロジック制御メカニズムとしてよりも、プロパティとして（たとえば、テーブルの列IDとして）使用する方が適切です。

質問で提示された問題を考えてみましょう。ここでのコンテキストや、この列挙型が何を表しているのかは本当にわかりません。絵カードですか？絵を描く？血を引く？順序は重要ですか？また、パフォーマンスがどれほど重要かわかりません。パフォーマンスまたはメモリが重要な場合、このソリューションはおそらくあなたが望むものではないでしょう。

いずれにせよ、列挙型を考えてみましょう：

// All possible combinations of One - Eight.
public enum ExampleEnum {
    One,
    Two,
    TwoOne,
    Three,
    ThreeOne,
    ThreeTwo,
    ThreeOneTwo
}

ここにあるのは、さまざまなビジネス概念を表すさまざまな列挙値です。

代わりに使用できるのは、物事を単純化するための抽象化です。

次のインターフェイスを考えてみましょう。

public interface IExample
{
  void Draw();
}

次に、これを抽象クラスとして実装できます。

public abstract class ExampleClassBase : IExample
{
  public abstract void Draw();
  // other common functionality defined here
}

描画1、2、3を表す具体的なクラスを持つことができます（引数のために異なるロジックがあります）。これらは上記で定義された基本クラスを使用する可能性がありますが、DrawOneの概念は、enumで表される概念とは異なると想定しています。

public class DrawOne
{
  public void Draw()
  {
    // Drawing logic here
  }
}

public class DrawTwo
{
  public void Draw()
  {
    // Drawing two logic here
  }
}

public class DrawThree
{
  public void Draw()
  {
    // Drawing three logic here
  }
}

そして今、他のクラスのロジックを提供するために構成できる3つの個別のクラスがあります。

public class One : ExampleClassBase
{
  private DrawOne drawOne;

  public One(DrawOne drawOne)
  {
    this.drawOne = drawOne;
  }

  public void Draw()
  {
    this.drawOne.Draw();
  }
}

public class TwoOne : ExampleClassBase
{
  private DrawOne drawOne;
  private DrawTwo drawTwo;

  public One(DrawOne drawOne, DrawTwo drawTwo)
  {
    this.drawOne = drawOne;
    this.drawTwo = drawTwo;
  }

  public void Draw()
  {
    this.drawOne.Draw();
    this.drawTwo.Draw();
  }
}

// the other six classes here

このアプローチははるかに冗長です。しかし、それには利点があります。

バグを含む次のクラスを検討してください。

public class ThreeTwoOne : ExampleClassBase
{
  private DrawOne drawOne;
  private DrawTwo drawTwo;
  private DrawThree drawThree;

  public One(DrawOne drawOne, DrawTwo drawTwo, DrawThree drawThree)
  {
    this.drawOne = drawOne;
    this.drawTwo = drawTwo;
    this.drawThree = drawThree;
  }

  public void Draw()
  {
    this.drawOne.Draw();
    this.drawTwo.Draw();
  }
}

欠落しているdrawThree.Draw（）呼び出しを見つけるのはどれくらい簡単ですか？また、順序が重要な場合は、描画呼び出しの順序も非常に簡単に確認および追跡できます。

このアプローチの欠点：

• 提示された8つのオプションのすべてに、個別のクラスが必要です
• これはより多くのメモリを使用します
• これにより、コードが表面的に大きくなります
• 時々、このアプローチは不可能ですが、それに対するいくつかのバリエーションがあります

このアプローチの利点：

• これらの各クラスは完全にテスト可能です。なぜなら
• 描画メソッドの循環的複雑度は低いです（理論的には、必要に応じてDrawOne、DrawTwo、またはDrawThreeクラスをモックできます）。
• 描画メソッドは理解可能である-開発者はメソッドが何をするのかを理解するためにノットに頭を縛る必要はない
• バグは見つけやすく、書くのが難しい
• クラスはより高いレベルのクラスに構成されます。つまり、ThreeThreeThreeクラスの定義は簡単です。

複雑なロジック制御コードをcaseステートメントに記述する必要があると感じるときはいつでも、この（または同様の）アプローチを検討してください。将来はあなたが幸せになります。

ここでスイッチを使用する場合は、各ケースを個別に処理するとコードが実際に高速になります

switch(exampleValue)
{
    case One:
        i++;
        break;
    case Two:
        i += 2;
        break;
    case OneAndTwo:
    case Three:
        i+=3;
        break;
    case OneAndThree:
        i+=4;
        break;
    case TwoAndThree:
        i+=5;
        break;
}

それぞれの場合に単一の算術演算のみが実行されます

また、gotoの使用を検討している場合は、他の人が述べているように、おそらくアルゴリズムを再考する必要があります（gotoを使用する理由かもしれませんが、C＃のケースフォールがないことは認めます）。エドガー・ダイクストラの有名な論文「God Statement考慮された有害」を参照してください

あなたの特定の例では、列挙から本当に必要なのは各ステップのdo / do-notインジケータであったため、3つのifステートメントを書き換えるソリューションはa switchよりも好ましく、受け入れられた答えにした方が良いです。

しかし、それほどきれいに動作しないより複雑なロジックがある場合goto、switchステートメントのsは紛らわしいと感じます。私はむしろこのようなものを見たいです：

switch (enumVal) {
    case ThreeOneTwo: DrawThree; DrawTwo; DrawOne; break;
    case ThreeTwo:    DrawThree; DrawTwo; break;
    case ThreeOne:    DrawThree; DrawOne; break;
    case TwoOne:      DrawTwo; DrawOne; break;
    case Two:         DrawTwo; break;
    default:          DrawOne; break;
}

これは完璧ではありませんが、gotos よりもこの方法の方が良いと思います。イベントのシーケンスが非常に長く、互いに重複しているため、各ケースの完全なシーケンスを綴るのが実際には意味をなさない場合、gotoコードの重複を減らすためよりもサブルーチンを好むでしょう。

最近、gotoキーワードを嫌う理由が本当にあるのかどうかはわかりません。これは間違いなく古風で、99％のユースケースでは必要ありませんが、理由は言語の機能です。

gotoキーワードを嫌う理由は、次のようなコードです

if (someCondition) {
    goto label;
}

string message = "Hello World!";

label:
Console.WriteLine(message);

おっと！それは明らかに機能しません。message変数は、そのコードパスに定義されていません。したがって、C＃はそれを通過しません。しかし、それは暗黙的かもしれません。検討する

object.setMessage("Hello World!");

label:
object.display();

そしてdisplay、その中にWriteLineステートメントがあると仮定します。

この種のバグはgoto、コードパスをわかりにくくするため、見つけにくい場合があります。

これは簡単な例です。実際の例はそれほど明白ではないと仮定します。label:との間に50行のコードがあるかもしれませんmessage。

この言語はgoto、使用方法を制限することでこれを修正するのに役立ち、ブロックからのみ下降します。しかし、C＃gotoはそのように制限されていません。コードを飛び越えることができます。さらに、を制限する場合はgoto、名前を変更することもできます。他の言語はbreak、ブロックから降りるために、番号（終了するブロックの数）またはラベル（ブロックの1つに）を使用します。

の概念gotoは、低レベルの機械語命令です。しかし、私たちがより高いレベルの言語を持っている理由は、可変スコープなどのより高いレベルの抽象化に限定されるためです。

つまりgoto、switchステートメント内でC＃を使用してケースからケースにジャンプする場合、それは合理的に無害です。各ケースはすでにエントリポイントです。gotoこの無害な使用法gotoをより危険な形式で圧縮するため、それを呼び出すことはその状況ではばかげているとまだ思います。私はむしろ彼らcontinueがそのようなものを使うことを望んでいます。しかし、何らかの理由で、彼らは言語を書く前に私に尋ねることを忘れていました。

このように多くの選択肢がある場合（そしてあなたが言うように、さらに多くの選択肢がある場合）、それはおそらくコードではなくデータです。

列挙値をアクションにマッピングするディクショナリを作成します。ディクショナリは、関数またはアクションを表す単純な列挙型として表されます。次に、コードを単純な辞書検索に要約し、関数値を呼び出すか、単純化された選択肢を切り替えることができます。

ループと、breakとcontinueの違いを使用します。

do {
  switch (exampleValue) {
    case OneAndTwo: i += 2; break;
    case OneAndThree: i += 3; break;
    case Two: i += 2; continue;
    case TwoAndThree: i += 2;
    // dropthrough
    case Three: i += 3; continue;
    default: break;
  }
  i++;
} while(0);