แนวทางปฏิบัติที่ดีที่สุดสำหรับ if / return

ฉันต้องการที่จะรู้ว่าสิ่งที่ถือว่าเป็นวิธีที่ดีกว่าของการกลับมาเมื่อฉันมีifคำสั่ง

ตัวอย่างที่ 1:

public bool MyFunction()
{
   // Get some string for this example
   string myString = GetString();

   if (myString == null)
   {
      return false;
   }
   else
   {
      myString = "Name " + myString;
      // Do something more here...
      return true;
   }
}

ตัวอย่างที่ 2:

public bool MyFunction()
{
   // Get some string for this example
   string myString = GetString();

   if (myString == null)
   {
      return false;
   }

   myString = "Name " + myString;
   // Do something more here...
   return true;
}

อย่างที่คุณเห็นในตัวอย่างฟังก์ชั่นทั้งสองจะกลับมาtrue/falseแต่มันเป็นความคิดที่ดีที่จะใส่elseคำสั่งเหมือนในตัวอย่างแรกหรือดีกว่าที่จะไม่ใส่มัน?

ตัวอย่างที่ 2 เรียกว่า block Guard เหมาะกว่าที่จะส่งคืน / ส่งข้อยกเว้นก่อนเวลาหากมีสิ่งผิดปกติ (พารามิเตอร์ไม่ถูกต้องหรือสถานะไม่ถูกต้อง) ในการไหลของลอจิกปกติจะดีกว่าที่จะใช้ตัวอย่างที่ 1

สไตล์ส่วนตัวของฉันคือการใช้ซิงเกิ้ลifสำหรับบล็อกป้องกันและif/ elseในรหัสการประมวลผลวิธีการจริง

ในกรณีนี้คุณกำลังใช้myString == nullเป็นเงื่อนไขการป้องกันดังนั้นฉันมักจะใช้ifรูปแบบเดียว

พิจารณาโค้ดที่ซับซ้อนกว่านี้เล็กน้อย:

ตัวอย่างที่ 1:

public bool MyFunction(myString: string){

    //guard block
    if (myString == null){
        return false;
    }
    else{
        //processing block
        myString = escapedString(myString);

        if (myString == "foo"){
            //some processing here
            return false;
        }
        else{
            myString = "Name " + myString;
            //other stuff
            return true;
        }
    }
}

ตัวอย่างที่ 2:

public bool MyFunction(myString: string){

    //guard block
    if (myString == null){
        return false;
    }

    //processing block
    myString = escapedString(myString);

    if (myString == "foo"){
        //some processing here
        return false;
    }
    else{
        myString = "Name " + myString;
        //other stuff
        return true;
    }
}

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

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

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

ส่วนตัวฉันชอบวิธีที่สอง ฉันรู้สึกว่ามันสั้นกว่ามีการเยื้องน้อยกว่าและอ่านง่ายกว่า

การปฏิบัติส่วนตัวของฉันคือต่อไปนี้:

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

ตัวอย่างเช่น:

public bool myFunction()
{
   // First parameter loading
   String myString = getString();

   // Location of "quick exits", see the second example
   // ...

   // declaration of external resources that MUST be released whatever happens
   // ...

   // the return variable (should think about giving it a default value or not) 
   // if you have no default value, declare it final! You will get compiler 
   // error when you try to set it multiple times or leave uninitialized!
   bool didSomething = false;

   try {
     if (myString != null)
     {
       myString = "Name " + myString;
       // Do something more here...

       didSomething = true;
     } else {
       // get other parameters and data
       if ( other conditions apply ) {
         // do something else
         didSomething = true;
       }
     }

     // Edit: previously forgot the most important advantage of this version
     // *** HOUSEKEEPING!!! ***

   } finally {

     // this is the common place to release all resources, reset all state variables

     // Yes, if you use try-finally, you will get here from any internal returns too.
     // As I said, it is only my taste that I like to have one, straightforward path 
     // leading here, and this works even if you don't use the try-finally version.

   }

   return didSomething;
}

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

ตัวอย่างเช่น:

public bool myFunction()
{
   String myString = getString();

   if (null == myString)
   {
     // there is nothing to do if myString is null
     return false;
   } 

   myString = "Name " + myString;
   // Do something more here...

   // not using return value variable now, because the operation is straightforward.
   // if the operation is complex, use the variable as the previous example.

   return true;
}

กฎ "one exit" ยังช่วยเมื่อการคำนวณต้องการทรัพยากรภายนอกที่คุณต้องปล่อยหรือระบุว่าคุณต้องรีเซ็ตก่อนออกจากฟังก์ชัน บางครั้งมีการเพิ่มภายหลังในระหว่างการพัฒนา ด้วยการออกหลายครั้งในอัลกอริทึมจึงเป็นการยากที่จะขยายสาขาทั้งหมดอย่างถูกต้อง (และหากมีข้อยกเว้นเกิดขึ้นควรปล่อย / รีเซ็ตในบล็อกในที่สุดเช่นกันเพื่อหลีกเลี่ยงผลข้างเคียงในกรณีพิเศษที่หายาก ... )

กรณีของคุณดูเหมือนจะตกอยู่ในหมวดหมู่ "ออกอย่างรวดเร็วก่อนที่จะทำงานจริง" และฉันจะเขียนมันเหมือนเวอร์ชัน 2 ตัวอย่างของคุณ

ฉันชอบจ้างบล็อกป้องกันที่ฉันสามารถทำได้ด้วยเหตุผลสองประการ:

1. พวกเขาอนุญาตให้ออกอย่างรวดเร็วเนื่องจากเงื่อนไขบางอย่าง
2. ลบความจำเป็นสำหรับความซับซ้อนและไม่จำเป็นถ้าคำสั่งในรหัสในภายหลัง

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

ฉันชอบวิธี "Fall through":

public bool MyFunction()
{
   string myString = GetString();

   if (myString != null)
   {
     myString = "Name " + myString;
     return true;
    }
    return false;
}

การกระทำมีเงื่อนไขเฉพาะสิ่งอื่นใดเป็นเพียงการเริ่มต้น "ตกผ่าน"

ถ้าฉันมีเงื่อนไขเดียวฉันจะไม่ใช้เวลามากเกินไปในการพิจารณาสไตล์ แต่ถ้าฉันมีเงื่อนไขการป้องกันที่หลากหลายฉันต้องการสไตล์ 2

รูปนี้ สมมติว่าการทดสอบนั้นซับซ้อนและคุณไม่ต้องการผูกมันไว้ในเงื่อนไข if-ORed เดียวเพื่อหลีกเลี่ยงความซับซ้อน:

//Style1
if (this1 != Right)
{ 
    return;
}
else if(this2 != right2)
{
    return;
}
else if(this3 != right2)
{
    return;
}
else
{
    //everything is right
    //do something
    return;
}

กับ

//Style 2
if (this1 != Right)
{ 
   return;
}
if(this2 != right2)
{
    return;
}
if(this3 != right2)
{
    return;
}


//everything is right
//do something
return;

ที่นี่มีสองข้อได้เปรียบหลัก

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

2. หากคุณจำเป็นต้องเพิ่ม / ลบเงื่อนไขหนึ่งคุณจะลดโอกาสในการเลอะบันไดทั้งหมด

ข้อดีอีกข้อหนึ่งคือคุณมีเครื่องมือจัดฟันน้อยกว่าหนึ่งชุด

นี่ควรเป็นเรื่องที่ฟังดูดีกว่า

If condition
  do something
else
  do somethingelse

เป็นการแสดงออกถึงตัวเองดีขึ้นแล้ว

if condition
  do something
do somethingelse

สำหรับวิธีการขนาดเล็กมันจะไม่แตกต่างกันมาก แต่สำหรับวิธีการแบบผสมขนาดใหญ่มันสามารถทำให้ยากที่จะเข้าใจเพราะมันจะไม่แยกอย่างถูกต้อง

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

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

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

ในตัวอย่างของคุณelseเห็นได้ชัดว่าไม่จำเป็น แต่ ...

เมื่ออ่านอย่างรวดเร็วผ่านบรรทัดของโค้ดดวงตามักจะมองที่เครื่องมือจัดฟันและการเยื้องเพื่อให้ได้แนวคิดเกี่ยวกับการไหลของรหัส ก่อนที่พวกเขาจะชำระจริง ๆ รหัส ดังนั้นการเขียนelseและการใส่เครื่องหมายวงเล็บและเยื้องรอบโค้ดที่สองทำให้ผู้อ่านเห็นได้เร็วขึ้นว่านี่เป็นสถานการณ์ "A หรือ B" โดยที่หนึ่งบล็อกหรือบล็อกอื่นจะรัน นั่นคือผู้อ่านเห็นวงเล็บและเยื้องก่อนที่พวกเขาเห็นหลังจากที่เริ่มต้นreturnif

ในความคิดของฉันนี่เป็นหนึ่งในกรณีที่หายากเหล่านั้นซึ่งการเพิ่มสิ่งที่ซ้ำซ้อนลงในรหัสทำให้สามารถอ่านได้มากขึ้นไม่น้อย

ฉันไม่ต้องการตัวอย่างเช่น 2 เพราะมันเห็นได้ชัดทันทีว่าฟังก์ชั่นส่งกลับบางสิ่งบางอย่าง แต่ยิ่งไปกว่านั้นฉันอยากกลับจากที่แห่งนี้:

public bool MyFunction()
{
    bool result = false;

    string myString = GetString();

    if (myString != nil) {
        myString = "Name " + myString;

        result = true;
    }

    return result;
}

ด้วยสไตล์นี้ฉันสามารถ:

1. ดูได้ทันทีว่าฉันคืนอะไร

2. จับผลลัพธ์ของการเรียกใช้ฟังก์ชันทุกครั้งด้วยจุดพักเดียว

สไตล์ส่วนตัวของฉันมีแนวโน้มที่จะไป

function doQuery(string) {
    if (!query(string)) {
        query("ABORT");
        return false;
    } // else
    if(!anotherquery(string) {
        query("ABORT");
        return false;
    } // else
    return true;
}

การใช้elseคำสั่งcommented-out เพื่อระบุการไหลของโปรแกรมและทำให้อ่านได้ แต่หลีกเลี่ยงการเยื้องขนาดใหญ่ที่สามารถเข้าถึงผ่านหน้าจอได้อย่างง่ายดายหากมีขั้นตอนมากมายที่เกี่ยวข้อง

ฉันจะเขียน

public bool SetUserId(int id)
{
   // Get user name from id
   string userName = GetNameById(id);

   if (userName != null)
   {
       // update local ID and userName
       _id = id;
       _userNameLabelText = "Name: " + userName;
   }

   return userName != null;
}

userName != nullผมชอบสไตล์นี้เพราะมันเป็นที่ชัดเจนที่สุดที่ฉันจะกลับมา

กฎง่ายๆของฉันคือการทำ if-return โดยไม่มีอย่างอื่น (ส่วนใหญ่เป็นข้อผิดพลาด) หรือทำ if-else - if chain เต็มไปหมด

วิธีนี้ฉันหลีกเลี่ยงการพยายามแฟนซีเกินไปกับการแตกแขนงของฉันเนื่องจากเมื่อใดก็ตามที่ฉันทำสิ่งที่ฉันเข้ารหัสตรรกะแอปพลิเคชันลงใน ifs ของฉันทำให้พวกเขายากที่จะรักษา (ตัวอย่างเช่นถ้า enum OK หรือ ERR และฉันเขียน ifs ทั้งหมดของฉัน การใช้ประโยชน์จากข้อเท็จจริงที่ว่า! ตกลง <-> ERR มันจะกลายเป็นความเจ็บปวดในตูดเพื่อเพิ่มตัวเลือกที่สามให้กับ enum ในครั้งต่อไป)

ตัวอย่างเช่นในกรณีของคุณฉันจะใช้แบบธรรมดาถ้าเนื่องจาก "return ถ้า null" เป็นรูปแบบทั่วไปและไม่น่าเป็นไปได้ที่คุณจะต้องกังวลเกี่ยวกับความเป็นไปได้ที่สาม (นอกเหนือจาก null / ไม่ใช่ null) ในอนาคต.

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

ฉันคิดว่ามีข้อผิดพลาดมากมายในตัวอย่างที่ 2 ที่ถนนอาจนำไปสู่รหัสที่ไม่ได้ตั้งใจ สิ่งที่น่าสนใจอันดับหนึ่งที่นี่ขึ้นอยู่กับตรรกะรอบ ๆ ตัวแปร 'myString' ดังนั้นจะมีความชัดเจนการทดสอบเงื่อนไขทั้งหมดควรเกิดขึ้นในการบัญชีรหัสบล็อกสำหรับตรรกะที่รู้จักและเริ่มต้น / ไม่รู้จัก

จะเกิดอะไรขึ้นถ้ารหัสต่อมาถูกนำมาใช้โดยไม่ได้ตั้งใจกับตัวอย่าง 2 ที่เปลี่ยนแปลง ouput อย่างมีนัยสำคัญ:

   if (myString == null)
   {
      return false;
   }

   //add some v1 update code here...
   myString = "And the winner is: ";
   //add some v2 update code here...
   //buried in v2 updates the following line was added
   myString = null;
   //add some v3 update code here...
   //Well technically this should not be hit because myString = null
   //but we already passed that logic
   myString = "Name " + myString;
   // Do something more here...
   return true;

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

ฉันให้ความเชื่อมั่นในเรื่องนี้กับ C # guidlines บน Codeplex (ลิงก์ไปยังที่นี่: http://csharpguidelines.codeplex.com/ ) ซึ่งระบุสิ่งต่อไปนี้:

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

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