สลับคำสั่งกับผลตอบแทน - ความถูกต้องของรหัส

สมมติว่าฉันมีรหัสใน C โดยมีโครงสร้างประมาณนี้:

switch (something)
{
    case 0:
      return "blah";
      break;

    case 1:
    case 4:
      return "foo";
      break;

    case 2:
    case 3:
      return "bar";
      break;

    default:
      return "foobar";
      break;
}

เห็นได้ชัดว่าbreaks ไม่จำเป็นสำหรับรหัสที่จะทำงานอย่างถูกต้อง แต่ดูเหมือนว่าจะเป็นการปฏิบัติที่ไม่ดีถ้าฉันไม่ใส่ให้ฉัน

คุณคิดอย่างไร? ลบออกได้ไหม หรือคุณจะเก็บไว้เพื่อเพิ่ม "ความถูกต้อง"?

ลบbreakคำสั่ง ซึ่งไม่จำเป็นและบางทีคอมไพเลอร์บางตัวอาจออกคำเตือน"รหัสที่ไม่สามารถเข้าถึงได้"

ฉันจะใช้วิธีที่แตกต่างไปจากเดิมอย่างสิ้นเชิง อย่าส่งกลับมาตรงกลางของวิธีการ / ฟังก์ชัน ให้ใส่ค่าที่ส่งคืนในตัวแปรโลคัลแทนแล้วส่งในตอนท้าย

โดยส่วนตัวแล้วฉันพบว่าสิ่งต่อไปนี้สามารถอ่านได้มากขึ้น:

String result = "";

switch (something) {
case 0:
  result = "blah";
  break;
case 1:
  result = "foo";
  break;
}

return result;

โดยส่วนตัวฉันจะลบผลตอบแทนและหยุดพัก ฉันจะใช้คำสั่ง switch เพื่อกำหนดค่าให้กับตัวแปร จากนั้นส่งกลับตัวแปรนั้นหลังคำสั่ง switch

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

ข้อยกเว้นประการหนึ่ง: การกลับมาก่อนเวลานั้นไม่เป็นไรหากตรวจพบพารามิเตอร์ที่ไม่ถูกต้องที่จุดเริ่มต้นของฟังก์ชันก่อนที่จะได้รับทรัพยากรใด ๆ

หยุดพักไว้ - คุณมีโอกาสน้อยที่จะประสบปัญหาหาก / เมื่อคุณแก้ไขโค้ดในภายหลังหากมีการหยุดพักแล้ว

ต้องบอกว่าหลายคน (รวมทั้งฉัน) ถือว่าเป็นการปฏิบัติที่ไม่ดีที่จะกลับมาจากช่วงกลางของฟังก์ชัน ตามหลักการแล้วฟังก์ชันควรมีจุดเข้าและจุดออกหนึ่งจุด

ลบออก มันเป็นสำนวนที่จะกลับมาจากcaseคำสั่งและเป็นเสียง "รหัสที่ไม่สามารถเข้าถึงได้" เป็นอย่างอื่น

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

ปกติฉันจะเขียนโค้ดโดยไม่มีพวกเขา IMO รหัสตายมีแนวโน้มที่จะบ่งบอกถึงความชุ่ยและ / หรือขาดความเข้าใจ

แน่นอนฉันจะพิจารณาบางสิ่งเช่น:

char const *rets[] = {"blah", "foo", "bar"};

return rets[something];

แก้ไข: แม้จะมีการแก้ไขโพสต์แนวคิดทั่วไปนี้ก็สามารถใช้ได้ดี:

char const *rets[] = { "blah", "foo", "bar", "bar", "foo"};

if ((unsigned)something < 5)
    return rets[something]
return "foobar";

ในบางจุดโดยเฉพาะอย่างยิ่งถ้าค่าอินพุตเบาบาง (เช่น 1, 100, 1000 และ 10,000) คุณต้องการอาร์เรย์แบบกระจัดกระจายแทน คุณสามารถใช้สิ่งนั้นเป็นต้นไม้หรือแผนที่ได้ดีพอสมควร (แต่แน่นอนว่าสวิตช์ยังคงใช้งานได้ในกรณีนี้เช่นกัน)

ฉันจะบอกว่าลบออกและกำหนดค่าเริ่มต้น: branch

จะดีกว่าไหมถ้ามีอาร์เรย์ด้วย

arr[0] = "blah"
arr[1] = "foo"
arr[2] = "bar"

และทำreturn arr[something];อย่างไร

หากเป็นเรื่องเกี่ยวกับการปฏิบัติโดยทั่วไปคุณควรเก็บbreakข้อความไว้ในสวิตช์ ในกรณีที่คุณไม่ต้องการreturnงบในอนาคตก็จะช่วยลดโอกาสที่จะตกลงไปในcaseอนาคต

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

คุณคิดอย่างไร? ลบออกได้ไหม หรือคุณจะเก็บไว้เพื่อเพิ่ม "ความถูกต้อง"?

สามารถลบออกได้ ใช้return เป็นว่าสถานการณ์ที่ breakไม่ควรใช้

น่าสนใจ. ฉันทามติจากคำตอบเหล่านี้ส่วนใหญ่ดูเหมือนว่าbreakคำสั่งที่ซ้ำซ้อนเป็นสิ่งที่ไม่จำเป็น ในทางกลับกันฉันอ่านbreakคำสั่งในสวิตช์เป็น 'ปิด' ของเคส caseบล็อกที่ไม่จบลงด้วยbreakแนวโน้มที่จะกระโดดออกมาที่ฉันเนื่องจากอาจมีข้อผิดพลาด

ฉันรู้ว่านั่นไม่ใช่วิธีที่เมื่อมี a returnแทนbreakแต่นั่นเป็นวิธีที่ตาของฉัน 'อ่าน' เคสบล็อกในสวิตช์ดังนั้นโดยส่วนตัวแล้วฉันอยากให้แต่ละcaseคู่จับคู่กับไฟล์break. แต่คอมไพเลอร์จำนวนมากไม่บ่นเกี่ยวกับbreakหลังจากที่returnฟุ่มเฟือย / ไม่สามารถเข้าถึงได้และดูเหมือนว่าฉันจะอยู่ในคนส่วนน้อยอยู่ดี

ดังนั้นกำจัดต่อไปbreakreturn

หมายเหตุ: ทั้งหมดนี้ไม่สนใจว่าการละเมิดกฎการเข้า / ออกครั้งเดียวเป็นความคิดที่ดีหรือไม่ เท่าที่ผ่านมาฉันมีความเห็นว่าน่าเสียดายที่เปลี่ยนแปลงไปตามสถานการณ์ ...

ฉันบอกว่าให้ลบออก หากรหัสของคุณไม่สามารถอ่านได้จนคุณต้องหยุดพักไว้ตรงนั้น 'เพื่ออยู่ในด้านที่ปลอดภัย' คุณควรพิจารณารูปแบบการเข้ารหัสของคุณใหม่ :)

นอกจากนี้ฉันมักไม่ชอบที่จะไม่ผสมตัวแบ่งและผลตอบแทนในคำสั่งสวิตช์ แต่ให้ยึดติดกับหนึ่งในนั้น

ฉันเองมักจะแพ้breaks สาเหตุหนึ่งของนิสัยนี้อาจมาจากขั้นตอนการเขียนโปรแกรมหน้าต่างสำหรับแอพ Windows:

LRESULT WindowProc (HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
    switch (uMsg)
    {
        case WM_SIZE:
            return sizeHandler (...);
        case WM_DESTROY:
            return destroyHandler (...);
        ...
    }

    return DefWindowProc(hwnd, uMsg, wParam, lParam);
}

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

ฉันคิดว่าตัวแบ่ง * มีไว้เพื่อจุดประสงค์ มันคือการรักษา 'อุดมการณ์' ของการเขียนโปรแกรมให้คงอยู่ หากเราเพียงแค่ 'ตั้งโปรแกรม' โค้ดของเราโดยไม่มีการเชื่อมโยงเชิงตรรกะบางทีคุณอาจอ่านได้ในตอนนี้ แต่ลองพรุ่งนี้ ลองอธิบายให้หัวหน้าของคุณฟัง ลองรันบน Windows 3030

Bleah แนวคิดนั้นง่ายมาก:

Switch ( Algorithm )
{

 case 1:
 {
   Call_911;
   Jump;
 }**break**;
 case 2:
 {
   Call Samantha_28;
   Forget;
 }**break**;
 case 3:
 {
   Call it_a_day;
 }**break**;

Return thinkAboutIt?1:return 0;

void Samantha_28(int oBed)
{
   LONG way_from_right;
   SHORT Forget_is_my_job;
   LONG JMP_is_for_assembly;
   LONG assembly_I_work_for_cops;

   BOOL allOfTheAbove;

   int Elligence_says_anyways_thinkAboutIt_**break**_if_we_code_like_this_we_d_be_monkeys;

}
// Sometimes Programming is supposed to convey the meaning and the essence of the task at hand. It is // there to serve a purpose and to keep it alive. While you are not looking, your program is doing  // its thing. Do you trust it?
// This is how you can...
// ----------
// **Break**; Please, take a **Break**;

/ * แค่คำถามเล็กน้อย คุณดื่มกาแฟมากแค่ไหนในขณะที่อ่านข้างต้น ไอทีทำให้ระบบพังในบางครั้ง * /

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

หากคุณมีรหัสประเภท "การค้นหา" คุณสามารถจัดแพคเกจประโยคกรณีสวิตช์ด้วยวิธีการด้วยตัวเอง

ฉันมีสิ่งเหล่านี้อยู่ในระบบ "งานอดิเรก" ที่ฉันกำลังพัฒนาเพื่อความสนุกสนาน:

private int basePerCapitaIncomeRaw(int tl) {
    switch (tl) {
        case 0:     return 7500;
        case 1:     return 7800;
        case 2:     return 8100;
        case 3:     return 8400;
        case 4:     return 9600;
        case 5:     return 13000;
        case 6:     return 19000;
        case 7:     return 25000;
        case 8:     return 31000;
        case 9:     return 43000;
        case 10:    return 67000;
        case 11:    return 97000;
        default:    return 130000;
    }
}

(ใช่นั่นคือพื้นที่ GURPS ... )

ฉันเห็นด้วยกับคนอื่น ๆ ว่าในกรณีส่วนใหญ่คุณควรหลีกเลี่ยงการส่งคืนมากกว่าหนึ่งวิธีและฉันตระหนักดีว่าอันนี้อาจได้รับการปรับใช้เป็นอาร์เรย์หรืออย่างอื่นได้ดีกว่า ฉันเพิ่งพบว่า switch-case-return เป็นการจับคู่ตารางการค้นหาที่ค่อนข้างง่ายโดยมีความสัมพันธ์ 1-1 ระหว่างอินพุตและเอาต์พุตเช่นเดียวกับสิ่งข้างต้น (เกมเล่นตามบทบาทเต็มไปด้วยพวกเขาฉันแน่ใจว่ามีอยู่ในเกมอื่น ๆ "ธุรกิจ" ด้วย): D

ในทางกลับกันถ้า case-clause มีความซับซ้อนมากขึ้นหรือมีบางอย่างเกิดขึ้นหลังจาก switch-statement ฉันไม่แนะนำให้ใช้ return แต่จะตั้งค่าตัวแปรในสวิตช์ปิดท้ายด้วยการหยุดพักและส่งคืน ค่าของตัวแปรในตอนท้าย

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