กลับคำสั่ง“ ถ้า” เพื่อลดการซ้อน

เมื่อฉันรันReSharperในรหัสของฉันตัวอย่างเช่น:

    if (some condition)
    {
        Some code...            
    }

ReSharper ให้คำเตือนข้างต้น (Invert "if" เพื่อลดการซ้อน) และแนะนำการแก้ไขต่อไปนี้:

   if (!some condition) return;
   Some code...

ฉันต้องการที่จะเข้าใจว่าทำไมถึงดีกว่า ฉันมักจะคิดว่าการใช้ "ส่งคืน" ตรงกลางของวิธีการที่มีปัญหานั้นค่อนข้างเหมือนกับ "goto"

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

double getPayAmount() {
    double result;
    if (_isDead) result = deadAmount();
    else {
        if (_isSeparated) result = separatedAmount();
        else {
            if (_isRetired) result = retiredAmount();
            else result = normalPayAmount();
        };
    }
     return result;
};

ในกรณีนี้หาก_isDeadเป็นจริงเราสามารถออกจากวิธีการได้ทันที มันอาจจะดีกว่าที่จะจัดโครงสร้างด้วยวิธีนี้แทน:

double getPayAmount() {
    if (_isDead)      return deadAmount();
    if (_isSeparated) return separatedAmount();
    if (_isRetired)   return retiredAmount();

    return normalPayAmount();
};   

ฉันเลือกรหัสนี้จากแคตตาล็อก refactoring การเปลี่ยนโครงสร้างใหม่นี้เรียกว่า: แทนที่เงื่อนไขที่ซ้อนกันด้วย Guard Clauses

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

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

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

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

นี่เป็นข้อโต้แย้งทางศาสนาเล็กน้อย แต่ฉันเห็นด้วยกับ ReSharper ว่าคุณควรเลือกทำรังน้อยกว่า ฉันเชื่อว่าสิ่งนี้มีค่ามากกว่าข้อเสียของการมีเส้นทางการส่งคืนหลายทางจากฟังก์ชัน

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

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

สำหรับเชิงลบเกี่ยวกับการคืนค่าหลาย ๆ ครั้งจากวิธีการ - debuggers นั้นค่อนข้างทรงพลังในตอนนี้และมันง่ายมากที่จะค้นหาว่าที่ไหนและเมื่อไรที่ฟังก์ชั่นหนึ่งกำลังกลับมา

การได้รับผลตอบแทนหลายครั้งในฟังก์ชั่นจะไม่ส่งผลกระทบต่องานของโปรแกรมเมอร์

การอ่านรหัสไม่ดีจะ

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

public void myfunction(double exampleParam){
    if(exampleParam > 0){
        //Body will *not* be executed if Double.IsNan(exampleParam)
    }
}

คมชัดว่ามีดูเหมือนผกผันเทียบเท่า:

public void myfunction(double exampleParam){
    if(exampleParam <= 0)
        return;
    //Body *will* be executed if Double.IsNan(exampleParam)
}

ดังนั้นในบางสถานการณ์สิ่งที่ดูเหมือนว่าจะเป็นกลับอย่างถูกต้องifอาจจะไม่

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

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

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

ฉันต้องการเพิ่มว่ามีชื่อสำหรับผู้ที่กลับหัวกลับหางหาก - คำสั่งป้องกัน ฉันใช้มันทุกครั้งที่ทำได้

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

http://c2.com/cgi/wiki?GuardClause

มันไม่เพียงส่งผลกระทบต่อความสวยงาม แต่ยังป้องกันการซ้อนโค้ด

มันสามารถทำหน้าที่เป็นเงื่อนไขเบื้องต้นเพื่อให้แน่ใจว่าข้อมูลของคุณถูกต้องเช่นกัน

แน่นอนว่าเป็นเรื่องส่วนตัว แต่ฉันคิดว่ามันจะดีขึ้นอย่างมากในสองประเด็น:

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

จุดคืนสินค้าหลายจุดเป็นปัญหาใน C (และในระดับที่น้อยกว่า C ++) เนื่องจากพวกเขาบังคับให้คุณทำซ้ำรหัสทำความสะอาดก่อนจุดส่งคืนแต่ละจุด ด้วยการรวบรวมขยะtry| finallyสร้างและusingบล็อกไม่มีเหตุผลจริงๆที่คุณควรกลัวพวกเขา

ในที่สุดมันก็มาถึงสิ่งที่คุณและเพื่อนร่วมงานของคุณอ่านง่ายขึ้น

ประสิทธิภาพที่ชาญฉลาดจะไม่มีความแตกต่างที่ชัดเจนระหว่างสองแนวทาง

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

มีโรงเรียนแห่งความคิดที่แข่งขันกันว่าจะเลือกวิธีไหนดีกว่า

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

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

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

if (something) {
    // a lot of indented code
}

คุณย้อนกลับเงื่อนไขและแบ่งถ้าเงื่อนไขที่ตรงกันข้ามนั้นเป็นจริง

if (!something) return false; // or another value to show your other code the function did not execute

// all the code from before, save a lot of tabs

returngotoไม่มีที่ไหนเลยใกล้สกปรกเหมือน อนุญาตให้คุณส่งค่าเพื่อแสดงรหัสที่เหลือที่ฟังก์ชันไม่สามารถทำงานได้

คุณจะเห็นตัวอย่างที่ดีที่สุดของสิ่งที่สามารถนำไปใช้ในสภาวะซ้อน:

if (something) {
    do-something();
    if (something-else) {
        do-another-thing();
    } else {
        do-something-else();
    }
}

VS:

if (!something) return;
do-something();

if (!something-else) return do-something-else();
do-another-thing();

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

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

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

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

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

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

เช่น.

 bool PerformDefaultOperation()
 {
      bool succeeded = false;

      DataStructure defaultParameters;
      if ((defaultParameters = this.GetApplicationDefaults()) != null)
      {
           succeeded = this.DoSomething(defaultParameters);
      }

      return succeeded;
 }

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

เหตุผลที่ดีมากเกี่ยวกับวิธีการรหัสที่มีลักษณะดังนี้ แต่แล้วผลลัพธ์ล่ะ

ลองดูโค้ด C # และรูปแบบ IL ที่คอมไพล์แล้ว:

using System;

public class Test {
    public static void Main(string[] args) {
        if (args.Length == 0) return;
        if ((args.Length+2)/3 == 5) return;
        Console.WriteLine("hey!!!");
    }
}

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

รหัส IL ที่สร้างขึ้นทำดังต่อไปนี้:

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

ดังนั้นดูเหมือนว่ารหัสจะข้ามไปยังจุดสิ้นสุด จะเกิดอะไรขึ้นถ้าหากเราทำรหัสปกติด้วยรหัสที่ซ้อนกัน?

using System;

public class Test {
    public static void Main(string[] args) {
        if (args.Length != 0 && (args.Length+2)/3 != 5) 
        {
            Console.WriteLine("hey!!!");
        }
    }
}

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

อย่างไรก็ตามตัวนับโปรแกรมจะกระโดดเสมอ

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

เพิ่มเติมเกี่ยวกับสาขาการทำนายที่นี่

นั่นเป็นเพียงการโต้เถียง ไม่มี "ข้อตกลงระหว่างโปรแกรมเมอร์" ในคำถามคืนต้น มันเป็นอัตนัยเสมอเท่าที่ฉันรู้

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

ฉันไม่คิดว่าคุณจะได้คำตอบที่เป็นข้อสรุปสำหรับคำถามนี้

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

ฉันพบรหัสของฉันอ่านไม่ได้จริง ๆ เมื่อเขียนแอปพลิเคชันโฮสต์ ASIO ด้วย ASIOSDK ของ Steinberg ขณะที่ฉันทำตามกระบวนทัศน์การทำรัง มันลึกถึงแปดระดับและฉันไม่สามารถเห็นข้อบกพร่องด้านการออกแบบที่นั่นดังที่ Andrew Bullock กล่าวไว้ข้างต้น แน่นอนว่าฉันสามารถบรรจุโค้ดภายในลงในฟังก์ชั่นอื่นแล้วซ้อนระดับที่เหลือเพื่อให้อ่านได้ง่ายขึ้น แต่นี่ดูเหมือนจะค่อนข้างสุ่มสำหรับฉัน

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

ดังนั้นนี่อาจเป็นสถานการณ์อื่นที่ ifs กลับหัวสามารถมีส่วนร่วมในรหัสที่ชัดเจนขึ้น

การหลีกเลี่ยงจุดออกหลายจุดสามารถทำให้ประสิทธิภาพเพิ่มขึ้น ฉันไม่แน่ใจเกี่ยวกับ C # แต่ใน C ++ การปรับค่าส่งคืนที่มีชื่อ (คัดลอก Elision, ISO C ++ '03 12.8 / 15) ขึ้นอยู่กับการมีจุดทางออกเดียว การเพิ่มประสิทธิภาพนี้หลีกเลี่ยงการคัดลอกการสร้างค่าตอบแทนของคุณ (ในตัวอย่างเฉพาะของคุณซึ่งไม่สำคัญ) สิ่งนี้อาจนำไปสู่การเพิ่มขึ้นอย่างมากของประสิทธิภาพการทำงานในลูปแน่นในขณะที่คุณบันทึกคอนสตรัคเตอร์และ destructor ในแต่ละครั้งที่มีการเรียกใช้ฟังก์ชัน

แต่สำหรับ 99% ของกรณีที่บันทึกการเรียกตัวสร้างและตัวทำลายเพิ่มเติมนั้นไม่คุ้มกับการสูญเสียifบล็อกที่ซ้อนกันที่สามารถอ่านได้ซึ่งแนะนำ

มันเป็นเรื่องของความเห็น

วิธีการปกติของฉันจะหลีกเลี่ยงบรรทัดเดียว ifs และส่งกลับในระหว่างวิธีการ

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

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

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

ฉันไม่แน่ใจ แต่ฉันคิดว่า R # พยายามหลีกเลี่ยงการกระโดดไกล เมื่อคุณมี IF-ELSE คอมไพเลอร์ก็ทำสิ่งนี้:

เงื่อนไขเป็นเท็จ -> ข้ามไปที่ false_condition_label

true_condition_label: คำแนะนำ 1 ... คำแนะนำ _n

false_condition_label: คำแนะนำ 1 ... คำแนะนำ _n

จบบล็อก

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

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

ความคิดของฉันคือการส่งคืน "กลางฟังก์ชัน" ไม่ควรเป็น "อัตนัย" เหตุผลค่อนข้างง่ายใช้รหัสนี้:

    ฟังก์ชัน do_something (ข้อมูล) {

      if (! is_valid_data (data)) 
            กลับเท็จ


       do_something_that_take_an_hour (ข้อมูล);

       istance = object_with_very_painful_constructor ใหม่ (ข้อมูล);

          ถ้า (istance ไม่ถูกต้อง) {
               ข้อความผิดพลาด( );
                กลับมา;

          }
       connect_to_database ();
       get_some_other_data ();
       กลับ;
    }

บางทีการ "ย้อนกลับ" ครั้งแรกอาจไม่ง่ายนัก แต่ก็ประหยัดจริงๆ มี "ความคิด" จำนวนมากเกินไปเกี่ยวกับรหัสที่สะอาดที่ต้องการเพียงการฝึกฝนให้มากขึ้น

มีข้อดีหลายประการสำหรับการเข้ารหัสประเภทนี้ แต่สำหรับฉันการชนะครั้งยิ่งใหญ่ก็คือหากคุณสามารถคืนรหัสได้อย่างรวดเร็วคุณสามารถปรับปรุงความเร็วของแอปพลิเคชันของคุณได้ IE ฉันรู้ว่าเนื่องจาก Precondition X ที่ฉันสามารถส่งคืนได้อย่างรวดเร็วพร้อมข้อผิดพลาด กรณีนี้จะได้รับการกำจัดข้อผิดพลาดก่อนและลดความซับซ้อนของรหัสของคุณ ในหลายกรณีเพราะตอนนี้ cpu ไปป์ไลน์สามารถสะอาดกว่าได้แล้วมันสามารถหยุดการขัดข้องหรือสวิทช์ไปป์ไลน์ได้ ประการที่สองถ้าคุณอยู่ในวงวนการแตกหักหรือถอยกลับอย่างรวดเร็วสามารถช่วยคุณประหยัดซีพียูได้มากมาย โปรแกรมเมอร์บางคนใช้ loop invariants เพื่อทำการออกอย่างรวดเร็ว แต่ในที่นี้คุณสามารถทำลาย cpu ไปป์ไลน์ของคุณและยังสร้างปัญหาการค้นหาหน่วยความจำและหมายความว่า cpu จำเป็นต้องโหลดจากแคชภายนอก แต่โดยพื้นฐานแล้วฉันคิดว่าคุณควรทำในสิ่งที่คุณตั้งใจไว้ นั่นคือการสิ้นสุดลูปหรือฟังก์ชั่นไม่ได้สร้างเส้นทางรหัสที่ซับซ้อนเพียงเพื่อใช้ความคิดที่เป็นนามธรรมของรหัสที่ถูกต้อง หากเครื่องมือเดียวที่คุณมีคือค้อนทุกอย่างดูเหมือนเล็บ