หลีกเลี่ยงวูดู `goto 'หรือไม่

ฉันมีswitchโครงสร้างที่มีหลายกรณีที่ต้องจัดการ การswitchดำเนินการมากกว่าenumที่ poses ปัญหาของรหัสที่ซ้ำกันผ่านค่ารวม:

// 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โครงสร้างที่มีการตกลงระหว่างกรณี

ฉันต้องใช้ a gotoในกรณีนั้นเนื่องจาก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เป็นบิตฟิลด์ที่แต่ละบิตแสดงตัวเลือกอย่างใดอย่างหนึ่งอาจเป็นดังนี้:

[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 แต่คุณสามารถทำได้โดยเปลี่ยนค่าของ enums ในตัวอย่างของคุณเป็น:

[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 แต่คุณได้แนวคิด) คุณยังสามารถตั้งชื่อชุดค่าผสมโดยใช้ค่าบิตหรือถ้าชุดค่าผสมอาจถูกตั้งค่าร่วมกันบ่อยครั้ง

IMO รากเหง้าของปัญหาคือรหัสชิ้นนี้ไม่ควรมีอยู่

เห็นได้ชัดว่าคุณมีเงื่อนไขที่เป็นอิสระสามประการและสามการกระทำที่เป็นอิสระที่จะทำหากเงื่อนไขเหล่านั้นเป็นจริง แล้วทำไมทุกสิ่งที่ถูกรวมเข้าเป็นส่วนหนึ่งของรหัสที่ต้องการธงบูลีนสามอันเพื่อบอกว่าจะต้องทำอะไร (ไม่ว่าคุณจะทำให้พวกเขากลายเป็นคนโง่) หรือไม่ หลักการความรับผิดชอบเดียวดูเหมือนว่าจะมีวันหยุดที่นี่

ใส่การเรียกไปยังสามฟังก์ชันที่เป็นของ (เช่นที่คุณค้นพบความจำเป็นในการดำเนินการ) และส่งรหัสในตัวอย่างเหล่านี้ไปยังถังรีไซเคิล

หากมีสิบค่าสถานะและการกระทำที่ไม่ใช่สามคุณจะขยายรหัสประเภทนี้เพื่อจัดการกับชุดค่าผสม 1024 ชุดที่แตกต่างกันหรือไม่ ฉันหวังว่าจะไม่! ถ้า 1024 มากเกินไป 8 ก็มากเกินไปด้วยเหตุผลเดียวกัน

อย่าใช้ gotosเป็นหนึ่งในแนวคิด"โกหกต่อเด็ก"ของวิทยาศาสตร์คอมพิวเตอร์ มันเป็นคำแนะนำที่ถูกต้อง 99% ของเวลาและเวลาที่มันไม่ได้หาได้ยากและมีความเชี่ยวชาญที่จะดีกว่าสำหรับทุกคนถ้ามันเพิ่งอธิบายให้ coders ใหม่ว่า "อย่าใช้มัน"

ดังนั้นควรใช้เมื่อใด มีบางสถานการณ์ : หนึ่งพื้นฐานที่คุณดูเหมือนจะตี แต่เมื่อคุณกำลังเข้ารหัสเครื่องรัฐ หากไม่มีการจัดระเบียบและโครงสร้างที่ดีกว่าอัลกอริธึมของคุณมากกว่าเครื่องสถานะการแสดงออกตามธรรมชาติในรหัสจะเกี่ยวข้องกับสาขาที่ไม่มีโครงสร้างและไม่มีอะไรมากมายที่สามารถทำได้เกี่ยวกับสิ่งที่ไม่ได้สร้างโครงสร้างของ เครื่องรัฐชัดเจนมากขึ้นมากกว่าน้อยกว่า

ผู้เขียนคอมไพเลอร์รู้สิ่งนี้ซึ่งเป็นสาเหตุที่ซอร์สโค้ดสำหรับคอมไพเลอร์ส่วนใหญ่ที่ใช้ตัวแยกวิเคราะห์ LALR ^*มี gotos อย่างไรก็ตามมีคนเพียงไม่กี่คนเท่านั้นที่จะเขียนโค้ดวิเคราะห์คำและตัวแยกวิเคราะห์

^{* - IIRC เป็นไปได้ที่จะใช้ไวยากรณ์ LALL ซ้ำทั้งหมดโดยไม่ต้องใช้วิธีกระโดดตารางหรือคำสั่งควบคุมที่ไม่มีโครงสร้างอื่น ๆ ดังนั้นหากคุณต่อต้านการข้ามไปอย่างแท้จริงนี่เป็นวิธีหนึ่ง}

ตอนนี้คำถามต่อไปคือ "นี่เป็นตัวอย่างหนึ่งในกรณีเหล่านี้หรือไม่"

สิ่งที่ฉันเห็นมันคือคุณมีสถานะถัดไปสามแบบที่แตกต่างกันขึ้นอยู่กับการประมวลผลสถานะปัจจุบัน เนื่องจากหนึ่งในนั้น ("ค่าเริ่มต้น") เป็นเพียงบรรทัดของรหัสในทางเทคนิคคุณสามารถกำจัดมันได้โดยการตรึงบรรทัดของรหัสนั้นไว้ที่ส่วนท้ายของสถานะที่ใช้ นั่นจะทำให้คุณมีสถานะเป็นไปได้ 2 สถานะ

หนึ่งในสิ่งที่เหลืออยู่ ("สาม") แยกจากที่เดียวที่ฉันเห็น ดังนั้นคุณสามารถกำจัดมันด้วยวิธีเดียวกัน คุณจะได้รหัสที่มีลักษณะดังนี้:

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

อย่างไรก็ตามนี่เป็นตัวอย่างของเล่นที่คุณให้อีกครั้ง ในกรณีที่ "ค่าเริ่มต้น" มีจำนวนรหัสที่ไม่สำคัญอยู่ในนั้น "สาม" จะถูกเปลี่ยนเป็นจากหลายรัฐหรือ (ที่สำคัญที่สุด) การบำรุงรักษาเพิ่มเติมมีแนวโน้มที่จะเพิ่มหรือทำให้ซับซ้อนรัฐคุณจะต้องดีกว่า ใช้ gotos (และอาจกำจัดโครงสร้าง enum-case ที่ซ่อนลักษณะของเครื่องจักรของสิ่งต่าง ๆ เว้นแต่จะมีเหตุผลที่ดีที่มันต้องอยู่)

คำตอบที่ดีที่สุดคือการใช้ความแตกต่าง

อีกคำตอบหนึ่งซึ่ง IMO ทำให้สิ่งที่ชัดเจนยิ่งขึ้นและสั้นลง :

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

ตกลงฉันเห็นด้วยนี่เป็นเรื่องแฮ็ค (ฉันไม่ใช่นักพัฒนา C # btw ขอโทษสำหรับรหัส) แต่จากมุมมองของประสิทธิภาพนี้ต้องเป็นอย่างไร ใช้ enums เป็นดัชนีอาเรย์ที่ถูกต้อง 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;
   }
}

ทางออกที่ยอมรับนั้นใช้ได้ดีและเป็นทางออกที่เป็นรูปธรรมสำหรับปัญหาของคุณ อย่างไรก็ตามฉันต้องการที่จะวางทางเลือกทางออกที่เป็นนามธรรมมากขึ้น

จากประสบการณ์ของฉันการใช้ enums เพื่อกำหนดการไหลของลอจิกเป็นกลิ่นรหัสเนื่องจากมักจะเป็นสัญญาณของการออกแบบระดับที่ไม่ดี

ฉันวิ่งเข้าไปในโลกแห่งความเป็นจริงของเหตุการณ์นี้ในรหัสที่ฉันทำงานเมื่อปีที่แล้ว นักพัฒนาดั้งเดิมได้สร้างคลาสเดียวซึ่งทำทั้งตรรกะการนำเข้าและส่งออกและสลับไปมาระหว่างทั้งสองโดยยึดตาม enum ตอนนี้รหัสนั้นคล้ายกันและมีรหัสซ้ำกัน แต่มันแตกต่างกันมากพอที่จะทำให้รหัสอ่านและทดสอบได้ยากขึ้น ฉันลงเอยด้วยการปรับโครงสร้างให้เป็นสองคลาสแยกกันซึ่งทำให้ทั้งสองอย่างง่ายขึ้นและให้ฉันเห็นและกำจัดข้อผิดพลาดที่ไม่ได้รายงานจำนวนมาก

อีกครั้งฉันต้องระบุว่าการใช้ enums เพื่อควบคุมการไหลของตรรกะมักจะเป็นปัญหาการออกแบบ ในกรณีทั่วไปควรใช้ Enums เป็นส่วนใหญ่เพื่อให้ค่าที่ปลอดภัยและเป็นมิตรกับผู้บริโภคโดยมีการกำหนดค่าที่เป็นไปได้อย่างชัดเจน พวกมันถูกใช้เป็นคุณสมบัติ (ตัวอย่างเช่นเป็น ID คอลัมน์ในตาราง) ดีกว่าเป็นกลไกควบคุมตรรกะ

ลองพิจารณาปัญหาที่นำเสนอในคำถาม ฉันไม่รู้บริบทจริง ๆ ที่นี่หรือสิ่งที่ enum นำเสนอ มันวาดการ์ดหรือไม่ กำลังวาดภาพ? วาดเลือดหรือไม่ คำสั่งซื้อสำคัญหรือไม่ ฉันไม่ทราบด้วยว่าประสิทธิภาพสำคัญเพียงใด หากประสิทธิภาพหรือหน่วยความจำมีความสำคัญโซลูชันนี้อาจไม่ตรงกับที่คุณต้องการ

ไม่ว่าในกรณีใดลองพิจารณา enum:

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

สิ่งที่เรามีที่นี่มีค่า enum ที่แตกต่างกันซึ่งแสดงถึงแนวคิดทางธุรกิจที่แตกต่างกัน

สิ่งที่เราสามารถใช้แทน abstractions เพื่อทำให้สิ่งต่าง ๆ ง่ายขึ้น

ขอให้เราพิจารณาอินเทอร์เฟซต่อไปนี้:

public interface IExample
{
  void Draw();
}

จากนั้นเราสามารถใช้สิ่งนี้เป็นคลาสนามธรรม:

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

เราสามารถมีคลาสที่เป็นรูปธรรมเพื่อเป็นตัวแทนของ Drawing One, สองและสาม (ซึ่งสำหรับเหตุผลของการโต้แย้งมีตรรกะที่แตกต่างกัน) สิ่งเหล่านี้อาจใช้คลาสพื้นฐานที่กำหนดไว้ด้านบน แต่ฉันสมมติว่าแนวคิด 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
  }
}

และตอนนี้เรามีคลาสที่แยกกันสามคลาสซึ่งอาจประกอบด้วยตรรกะเพื่อให้คลาสอื่น

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 () ที่หายไป? และถ้าลำดับเป็นสิ่งสำคัญลำดับของการเรียกเสมอก็ง่ายต่อการดูและติดตาม

ข้อเสียของวิธีนี้:

• ทุกหนึ่งในแปดตัวเลือกที่นำเสนอต้องแยกชั้นเรียน
• นี้จะใช้หน่วยความจำเพิ่มเติม
• สิ่งนี้จะทำให้โค้ดของคุณมีขนาดใหญ่ขึ้นอย่างมาก
• บางครั้งวิธีการนี้เป็นไปไม่ได้แม้ว่าจะมีความแตกต่างอยู่บ้าง

ข้อดีของวิธีนี้:

• แต่ละคลาสเหล่านี้สามารถทดสอบได้อย่างสมบูรณ์ เพราะ
• ความซับซ้อนของวงจรวิธีการวาดอยู่ในระดับต่ำ (และในทางทฤษฎีแล้วฉันสามารถล้อเลียนชั้นเรียน DrawOne, DrawTwo หรือ DrawThree ได้ถ้าจำเป็น)
• วิธีการวาดเป็นที่เข้าใจได้ - นักพัฒนาไม่จำเป็นต้องผูกสมองของพวกเขาเป็นปมเพื่อหาวิธีที่จะทำ
• จุดบกพร่องนั้นง่ายต่อการสังเกตและเขียนยาก
• คลาสที่ประกอบเป็นคลาสระดับสูงมากขึ้นซึ่งหมายความว่าการกำหนดคลาส ThreeThreeThree ทำได้ง่าย

พิจารณาวิธีการนี้ (หรือคล้ายกัน) เมื่อใดก็ตามที่คุณรู้สึกว่าจำเป็นต้องมีรหัสควบคุมตรรกะที่ซับซ้อนใด ๆ ที่เขียนลงในคำสั่งกรณี ในอนาคตคุณจะมีความสุขที่คุณทำ

หากคุณต้องการใช้สวิตช์ที่นี่รหัสของคุณจะเร็วขึ้นหากคุณจัดการแต่ละกรณีแยกกัน

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

มีการดำเนินการทางคณิตศาสตร์เพียงอย่างเดียวในแต่ละกรณี

เช่นเดียวกับที่คนอื่น ๆ ได้กล่าวไว้หากคุณกำลังพิจารณาใช้ gotos คุณควรคิดใหม่อัลกอริทึมของคุณ (แม้ว่าฉันจะยอมรับว่ากรณีของ C # นั้นล้มเหลว แต่อาจเป็นเหตุผลที่ใช้ goto) ดูบทความที่มีชื่อเสียงของ Edgar Dijkstra "Go To Statement พิจารณาว่าเป็นอันตราย"

สำหรับตัวอย่างเฉพาะของคุณเนื่องจากทั้งหมดที่คุณต้องการจากการแจงนับเป็นตัวบ่งชี้ที่ต้องทำ / ไม่ต้องทำสำหรับแต่ละขั้นตอนวิธีการแก้ปัญหาที่เขียนใหม่สามifคำสั่งของคุณจะดีกว่าswitchและเป็นสิ่งที่ดีที่คุณทำให้เป็นคำตอบที่ยอมรับ .

แต่ถ้าคุณมีบางตรรกะที่ซับซ้อนมากขึ้นที่ไม่ได้ทำงานออกเพื่อให้หมดจดแล้วฉันยังคงพบว่าgotos ในswitchคำสั่งทำให้เกิดความสับสน ฉันอยากเห็นสิ่งนี้:

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การลดรหัสซ้ำ

ฉันไม่แน่ใจว่าทุกคนมีเหตุผลที่จะเกลียดคำหลักข้ามไปเมื่อเร็ว ๆ นี้ เป็นของโบราณและไม่จำเป็นใน 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:message

ภาษาสามารถช่วยแก้ไขปัญหานี้ได้ด้วยการ จำกัด วิธีการgotoใช้งานโดยสามารถลดระดับลงได้จากบล็อกเท่านั้น แต่ C # gotoไม่ จำกัด เช่นนั้น มันสามารถข้ามรหัส นอกจากนี้หากคุณกำลังจะ จำกัดgotoก็แค่เปลี่ยนชื่อ ภาษาอื่นใช้breakสำหรับลดหลั่นจากบล็อกทั้งที่มีหมายเลข (ของบล็อกเพื่อออก) หรือป้ายกำกับ (บนหนึ่งในบล็อก)

แนวคิดของgotoการเรียนการสอนภาษาเครื่องในระดับต่ำ แต่เหตุผลทั้งหมดว่าทำไมเราถึงมีภาษาระดับสูงขึ้นเพื่อที่เราจะ จำกัด เฉพาะนามธรรมระดับสูงเช่นขอบเขตของตัวแปร

ทุกอย่างที่กล่าวว่าหากคุณใช้ C # gotoภายในswitchคำสั่งเพื่อข้ามจากกรณีหนึ่งไปยังอีกกรณีหนึ่งก็ไม่เป็นอันตรายอย่างมีเหตุผล แต่ละกรณีเป็นจุดเริ่มต้นแล้ว ฉันยังคงคิดว่าการเรียกมันว่าgotoเป็นเรื่องโง่ ๆ ในสถานการณ์นั้นเพราะมันทำให้การใช้งานไม่เป็นอันตรายgotoกับรูปแบบที่อันตรายกว่านี้ ฉันจะค่อนข้างมากว่าพวกเขาใช้สิ่งที่ต้องการcontinueสำหรับการที่ แต่ด้วยเหตุผลบางอย่างพวกเขาลืมถามฉันก่อนที่พวกเขาจะเขียนภาษา

เมื่อคุณมีตัวเลือกมากมาย (และยิ่งกว่านั้นอย่างที่คุณพูด) ดังนั้นอาจไม่ใช่รหัส แต่เป็นข้อมูล

สร้างค่า enum การแมปพจนานุกรมให้กับการกระทำซึ่งแสดงว่าเป็นฟังก์ชันหรือเป็นประเภท enum ที่ง่ายกว่าซึ่งแสดงถึงการกระทำ จากนั้นรหัสของคุณสามารถถูกต้มลงในการค้นหาพจนานุกรมอย่างง่ายตามด้วยการเรียกค่าฟังก์ชันหรือสวิตช์ในตัวเลือกที่ง่าย

ใช้การวนซ้ำและความแตกต่างระหว่างตัวแบ่งและต่อ

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