Vermeiden Sie das "goto" -Voodoo?

Ich habe eine switchStruktur, die mehrere Fälle zu behandeln hat. Das switchfunktioniert über ein, enumdas die Ausgabe des doppelten Codes durch kombinierte Werte aufwirft:

// 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.
}

Derzeit behandelt die switchStruktur jeden Wert separat:

// 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;
     ...
}

Sie bekommen die Idee dort. Ich habe dies derzeit in eine gestapelte ifStruktur unterteilt, um stattdessen Kombinationen mit einer einzelnen Zeile zu behandeln:

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

Dies wirft das Problem von unglaublich langen logischen Auswertungen auf, die verwirrend zu lesen und schwierig zu warten sind. Nachdem ich dies überarbeitet hatte, begann ich über Alternativen nachzudenken und über die Idee einer switchStruktur mit Fall-Through-zwischen-Fällen nachzudenken .

Ich muss gotoin diesem Fall ein verwenden, da C#es kein Durchfallen zulässt. Es verhindert jedoch die unglaublich langen logischen Ketten, obwohl es in der switchStruktur herumspringt, und bringt immer noch Code-Duplizierung mit sich.

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;
}

Dies ist immer noch keine saubere Lösung und es gibt ein Stigma im Zusammenhang mit dem gotoKeyword, das ich vermeiden möchte. Ich bin mir sicher, dass es einen besseren Weg geben muss, das aufzuräumen.

Meine Frage

Gibt es eine bessere Möglichkeit, diesen speziellen Fall zu behandeln, ohne die Lesbarkeit und Wartbarkeit zu beeinträchtigen?

Ich finde den Code mit den gotoAussagen schwer zu lesen . Ich würde empfehlen, Ihre enumanders zu strukturieren . Wenn es sich bei Ihrem Beispiel enumum ein Bitfeld handelt, in dem jedes Bit eine der Auswahlmöglichkeiten darstellt, könnte dies folgendermaßen aussehen:

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

Das Attribut Flags teilt dem Compiler mit, dass Sie Werte einrichten, die sich nicht überlappen. Der Code, der diesen Code aufruft, könnte das entsprechende Bit setzen. Sie könnten dann so etwas tun, um zu verdeutlichen, was passiert:

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

Dies erfordert den Code, myEnumder eingerichtet wird, um die Bitfelder ordnungsgemäß festzulegen und mit dem Attribut Flags zu kennzeichnen. Sie können dies jedoch tun, indem Sie die Werte der Aufzählungen in Ihrem Beispiel wie folgt ändern:

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

Wenn Sie eine Zahl in das Formular schreiben 0bxxxx, geben Sie diese binär an. Sie können also sehen, dass wir Bit 1, 2 oder 3 setzen (technisch gesehen 0, 1 oder 2, aber Sie haben die Idee). Sie können Kombinationen auch mit einem bitweisen ODER benennen, wenn die Kombinationen häufig zusammengesetzt werden.

IMO ist die Wurzel des Problems, dass dieses Stück Code nicht einmal existieren sollte.

Anscheinend müssen Sie drei unabhängige Bedingungen und drei unabhängige Aktionen ausführen, wenn diese Bedingungen erfüllt sind. Warum wird all das in einem Code zusammengefasst, der drei Boolesche Flags benötigt, um zu bestimmen, was zu tun ist (ob Sie sie in eine Aufzählung verschleiern oder nicht), und führt dann eine Kombination aus drei unabhängigen Dingen aus? Das Prinzip der Einzelverantwortung scheint hier einen Ruhetag zu haben.

Rufen Sie die drei Funktionen auf, zu denen sie gehören (dh, Sie stellen fest, dass die Aktionen ausgeführt werden müssen), und geben Sie den Code in diesen Beispielen in den Papierkorb.

Wenn es zehn Flags und keine drei Aktionen gäbe, würden Sie diese Art von Code erweitern, um 1024 verschiedene Kombinationen zu verarbeiten? Ich hoffe nicht! Wenn 1024 zu viel ist, ist 8 aus dem gleichen Grund auch zu viel.

Niemals gotos benutzen ist eine der "Lügen an Kinder" -Konzepte der Informatik. Es ist in 99% der Fälle der richtige Ratschlag, und die Zeiten, in denen es nicht so selten und spezialisiert ist, sind weitaus besser für alle, wenn es nur neuen Programmierern als "Verwenden Sie sie nicht" erklärt wird.

Wann sollten sie verwendet werden? Es gibt einige Szenarien , aber die grundlegende, die Sie zu treffen scheinen, ist: Wenn Sie eine Zustandsmaschine codieren . Wenn es keinen besser organisierten und strukturierten Ausdruck Ihres Algorithmus gibt als einen Zustandsautomaten, dann beinhaltet sein natürlicher Ausdruck im Code unstrukturierte Verzweigungen, und es kann nicht viel getan werden, um die Struktur des Algorithmus nicht zu beeinflussen Zustandsmaschine selbst eher undurchsichtig als weniger.

Compiler-Autoren wissen dies, weshalb der Quellcode für die meisten Compiler, die LALR-Parser ^* implementieren, gotos enthält. Allerdings werden nur sehr wenige Menschen jemals ihre eigenen lexikalischen Analysatoren und Parser codieren.

^{* - IIRC, es ist möglich, LALL-Grammatiken vollständig rekursiv zu implementieren, ohne auf Sprungtabellen oder andere unstrukturierte Steueranweisungen zurückzugreifen. Wenn Sie also wirklich gegen Goto sind, ist dies ein Ausweg.}

Nun lautet die nächste Frage: "Ist dieses Beispiel einer dieser Fälle?"

Was ich sehe, ist, dass Sie drei verschiedene mögliche nächste Zustände haben, abhängig von der Verarbeitung des aktuellen Zustands. Da einer von ihnen ("default") nur eine Codezeile ist, können Sie ihn technisch entfernen, indem Sie diese Codezeile am Ende der Zustände anheften, für die er gilt. Das würde Sie auf 2 mögliche nächste Zustände bringen.

Einer der verbleibenden ("Drei") ist nur von einer Stelle abgezweigt, die ich sehen kann. So können Sie es auf die gleiche Weise loswerden. Am Ende würden Sie Code haben, der so aussieht:

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;
}

Dies war jedoch wieder ein Spielzeugbeispiel, das Sie zur Verfügung gestellt haben. In Fällen, in denen "default" eine nicht triviale Menge an Code enthält, wird "three" aus mehreren Zuständen übernommen, oder (was am wichtigsten ist) eine weitere Wartung wird wahrscheinlich die Zustände ergänzen oder komplizieren , sind Sie ehrlich gesagt besser dran Verwenden von gotos (und vielleicht sogar die Enum-Case-Struktur loswerden, die die Zustandsmaschinen-Natur der Dinge verbirgt, es sei denn, es gibt einen guten Grund, warum es bleiben muss).

Die beste Antwort ist Polymorphismus .

Eine andere Antwort, die, IMO, das Wenn-Zeug klarer und wohl kürzer macht :

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

goto ist wahrscheinlich meine 58. Wahl hier ...

Warum nicht das:

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, ich stimme zu, das ist hackisch (ich bin übrigens kein C # -Entwickler, entschuldigen Sie mich für den Code), aber aus Sicht der Effizienz ist dies ein Muss? Die Verwendung von Enums als Array-Index ist in C # zulässig.

Wenn Sie keine Flags verwenden können oder möchten, verwenden Sie eine rekursive Schwanzfunktion. Im 64-Bit-Release-Modus erzeugt der Compiler Code, der Ihrer gotoAnweisung sehr ähnlich ist . Du musst dich einfach nicht damit auseinandersetzen.

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;
   }
}

Die akzeptierte Lösung ist in Ordnung und eine konkrete Lösung für Ihr Problem. Ich möchte jedoch eine alternative, abstraktere Lösung vorschlagen.

Nach meiner Erfahrung ist die Verwendung von Aufzählungen zur Definition des Logikflusses ein Codegeruch, da dies oft ein Zeichen für ein schlechtes Klassendesign ist.

Ich bin auf ein Beispiel aus der Praxis gestoßen, das in Code vorkommt, an dem ich letztes Jahr gearbeitet habe. Der ursprüngliche Entwickler hatte eine einzelne Klasse erstellt, die sowohl Import- als auch Exportlogik ausführte, und anhand einer Aufzählung zwischen den beiden Klassen gewechselt. Jetzt war der Code ähnlich und hatte einige doppelte Codes, aber es war anders genug, dass dies das Lesen des Codes erheblich erschwerte und das Testen praktisch unmöglich machte. Am Ende habe ich das in zwei separate Klassen umgestaltet, die beide Klassen vereinfachten und es mir ermöglichten, eine Reihe von nicht gemeldeten Fehlern zu erkennen und zu beseitigen.

Ich muss noch einmal feststellen, dass die Verwendung von Aufzählungen zur Steuerung des Logikflusses häufig ein Entwurfsproblem darstellt. Im Allgemeinen sollten Enums hauptsächlich verwendet werden, um typsichere, verbraucherfreundliche Werte bereitzustellen, bei denen die möglichen Werte klar definiert sind. Sie werden besser als Eigenschaft (z. B. als Spalten-ID in einer Tabelle) als als Logiksteuerungsmechanismus verwendet.

Betrachten wir das in der Frage dargestellte Problem. Ich kenne den Kontext hier nicht wirklich, oder was diese Aufzählung darstellt. Zeichnet es Karten? Bilder malen? Blut abnehmen? Ist Ordnung wichtig? Ich weiß auch nicht, wie wichtig Leistung ist. Wenn Leistung oder Arbeitsspeicher kritisch sind, ist diese Lösung wahrscheinlich nicht die gewünschte.

Betrachten wir auf jeden Fall die Aufzählung:

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

Was wir hier haben, sind eine Reihe von verschiedenen Aufzählungswerten, die unterschiedliche Geschäftskonzepte darstellen.

Wir könnten stattdessen Abstraktionen verwenden, um die Dinge zu vereinfachen.

Betrachten wir die folgende Schnittstelle:

public interface IExample
{
  void Draw();
}

Wir können dies dann als abstrakte Klasse implementieren:

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

Wir können eine konkrete Klasse haben, um Zeichnung eins, zwei und drei darzustellen (die aus Gründen der Argumentation eine andere Logik haben). Diese könnten möglicherweise die oben definierte Basisklasse verwenden, aber ich gehe davon aus, dass sich das DrawOne-Konzept von dem durch die Aufzählung dargestellten Konzept unterscheidet:

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
  }
}

Und jetzt haben wir drei separate Klassen, die zusammengesetzt werden können, um die Logik für die anderen Klassen bereitzustellen.

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

Dieser Ansatz ist weitaus ausführlicher. Aber es hat Vorteile.

Betrachten Sie die folgende Klasse, die einen Fehler enthält:

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();
  }
}

Wie viel einfacher ist es, den fehlenden Aufruf von drawThree.Draw () zu erkennen? Und wenn die Reihenfolge wichtig ist, ist die Reihenfolge der Draw Calls auch sehr einfach zu sehen und zu befolgen.

Nachteile dieses Ansatzes:

• Jede der acht vorgestellten Optionen erfordert eine eigene Klasse
• Dadurch wird mehr Speicher benötigt
• Dadurch wird Ihr Code oberflächlich größer
• Manchmal ist dieser Ansatz nicht möglich, auch wenn es Abweichungen gibt

Vorteile dieses Ansatzes:

• Jede dieser Klassen ist vollständig testbar; da
• Die zyklomatische Komplexität der Zeichenmethoden ist gering (und theoretisch könnte ich die DrawOne-, DrawTwo- oder DrawThree-Klassen bei Bedarf verspotten).
• Die Zeichenmethoden sind verständlich - ein Entwickler muss nicht sein Gehirn in Knoten binden, um herauszufinden, was die Methode tut
• Bugs sind leicht zu erkennen und schwer zu schreiben
• Klassen werden zu Klassen höherer Ebene zusammengefasst, was bedeutet, dass das Definieren einer ThreeThreeThree-Klasse einfach ist

Ziehen Sie diesen (oder einen ähnlichen) Ansatz in Betracht, wenn Sie das Gefühl haben, komplexen Logiksteuercode in case-Anweisungen schreiben zu müssen. Zukünftig wirst du froh sein, dass du es getan hast.

Wenn Sie beabsichtigen, hier einen Schalter zu verwenden, ist Ihr Code tatsächlich schneller, wenn Sie jeden Fall separat behandeln

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;
}

es wird jeweils nur eine einzige Rechenoperation durchgeführt

auch wie andere angegeben haben, sollten Sie, wenn Sie überlegen, gotos zu verwenden, wahrscheinlich Ihren Algorithmus überdenken (obwohl ich zugeben werde, dass C # mangelnde Groß- und Kleinschreibung ein Grund sein könnte, goto zu verwenden). Siehe Edgar Dijkstra berühmte Zeitung "Go To Statement als schädlich"

Da für Ihr spezielles Beispiel von der Aufzählung nur ein Do / Do-Indikator für jeden der Schritte gewünscht wurde, ist die Lösung, die Ihre drei ifAnweisungen umschreibt , einer vorzuziehen switch, und es ist gut, dass Sie sie zur akzeptierten Antwort gemacht haben .

Aber wenn Sie eine komplexere Logik hatten, die nicht so sauber funktioniert hat, dann finde ich das gotos in der switchAnweisung immer noch verwirrend. Ich würde eher so etwas sehen:

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;
}

Das ist nicht perfekt, aber ich denke, es ist besser so als mit dem gotos. Wenn die Sequenzen von Ereignissen so lang sind und sich so stark duplizieren, dass es wirklich keinen Sinn macht, die vollständige Sequenz für jeden Fall zu buchstabieren, bevorzuge ich eine Subroutine goto, um die Doppelung von Code zu reduzieren.

Ich bin mir nicht sicher, ob irgendjemand in diesen Tagen wirklich einen Grund hat, das goto-Schlüsselwort zu hassen. Es ist definitiv archaisch und wird in 99% der Anwendungsfälle nicht benötigt, aber es ist aus einem bestimmten Grund ein Merkmal der Sprache.

Der Grund, das gotoSchlüsselwort zu hassen, ist Code wie

if (someCondition) {
    goto label;
}

string message = "Hello World!";

label:
Console.WriteLine(message);

Hoppla! Das wird natürlich nicht funktionieren. Die messageVariable ist in diesem Codepfad nicht definiert. Also wird C # das nicht bestehen. Aber es könnte implizit sein. Erwägen

object.setMessage("Hello World!");

label:
object.display();

Und davon ausgehen, dass displaydann die WriteLineAussage drin ist.

Diese Art von Fehler kann schwer zu finden sein, da der gotoCodepfad verdeckt wird.

Dies ist ein vereinfachtes Beispiel. Angenommen, ein reales Beispiel wäre bei weitem nicht so offensichtlich. Zwischen label:und der Verwendung von können fünfzig Codezeilen liegen message.

Die Sprache kann Abhilfe schaffen, indem sie die Verwendungsmöglichkeiten einschränkt gotound nur aus Blöcken heraus absteigt. Aber das C # gotoist nicht so begrenzt. Es kann über Code springen. Wenn Sie einschränken möchten goto, ist es außerdem gut, den Namen zu ändern. Andere Sprachen breakwerden zum Verlassen von Blöcken verwendet, entweder mit einer Nummer (Anzahl der zu beendenden Blöcke) oder einer Bezeichnung (auf einem der Blöcke).

Das Konzept von gotoist eine Maschinensprachenanweisung auf niedriger Ebene. Der ganze Grund, warum wir über höhere Sprachen verfügen, ist, dass wir uns auf die höheren Abstraktionen beschränken, z. B. den variablen Umfang.

Alles in allem, wenn Sie das C # gotoin einer switchAnweisung verwenden, um von Fall zu Fall zu springen, ist dies einigermaßen harmlos. Jeder Fall ist bereits ein Einstiegspunkt. Ich denke immer noch, dass es gotodumm ist , es in dieser Situation zu nennen, da es diesen harmlosen Gebrauch gotomit gefährlicheren Formen in Verbindung bringt . Mir wäre es viel lieber, wenn sie so etwas benutzen würden continue. Aber aus irgendeinem Grund haben sie vergessen, mich zu fragen, bevor sie die Sprache geschrieben haben.

Wenn Sie so viele Möglichkeiten haben (und, wie Sie sagen, noch mehr), dann ist es vielleicht kein Code, sondern Daten.

Erstellen Sie ein Wörterbuch, in dem die Aufzählungswerte den Aktionen zugeordnet werden, entweder als Funktionen oder als einfacher Aufzählungstyp, der die Aktionen darstellt. Dann kann Ihr Code zu einem einfachen Nachschlagen des Wörterbuchs zusammengefasst werden, gefolgt vom Aufrufen des Funktionswerts oder dem Einschalten der vereinfachten Auswahlmöglichkeiten.

Verwenden Sie eine Schleife und den Unterschied zwischen break und 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);