การใช้วิธีกลับภายในโมฆะเป็นวิธีปฏิบัติที่ไม่ดีหรือไม่?

Question 1

ลองนึกภาพรหัสต่อไปนี้:

void DoThis()
{
    if (!isValid) return;

    DoThat();
}

void DoThat() {
    Console.WriteLine("DoThat()");
}

สามารถใช้ return ภายใน void method ได้หรือไม่? มันมีโทษประสิทธิภาพหรือไม่? หรือจะดีกว่าถ้าเขียนโค้ดแบบนี้:

void DoThis()
{
    if (isValid)
    {
        DoThat();
    }
}

Question 2

ผลตอบแทนในวิธีการที่เป็นโมฆะไม่ได้เลวร้ายเป็นเรื่องธรรมดาที่จะคว่ำifงบเพื่อลดการทำรัง

และการมีวิธีการซ้อนกันน้อยลงช่วยเพิ่มความสามารถในการอ่านโค้ดและการบำรุงรักษา

จริงๆแล้วถ้าคุณมีเมธอด void โดยไม่มีคำสั่ง return คอมไพลเลอร์จะสร้างคำสั่ง retที่ท้ายคำสั่งเสมอ

Question 3

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

พิจารณา:

void MyFunc(object obj)
{
    if (obj != null)
    {
        obj.DoSomething();
    }
}

เทียบกับ:

void MyFunc(object obj)
{
    if (obj == null)
        return;

    obj.DoSomething();
}

ลองนึกภาพโปรแกรมเมอร์คนอื่นเพิ่มบรรทัด: obj.DoSomethingElse ();

void MyFunc(object obj)
{
    if (obj != null)
    {
        obj.DoSomething();
    }

    obj.DoSomethingElse();
}

void MyFunc(object obj)
{
    if (obj == null)
        return;

    obj.DoSomething();
    obj.DoSomethingElse();
}

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

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

Question 4

ปฏิบัติไม่ดี ??? ไม่มีทาง. ในความเป็นจริงการจัดการการตรวจสอบความถูกต้องจะดีกว่าเสมอโดยการส่งคืนจากวิธีการอย่างเร็วที่สุดหากการตรวจสอบล้มเหลว มิฉะนั้นจะส่งผลให้ ifs & elses ซ้อนกันจำนวนมาก การยุติก่อนกำหนดช่วยเพิ่มความสามารถในการอ่านโค้ด

ตรวจสอบคำตอบในคำถามที่คล้ายกัน: ฉันควรใช้คำสั่ง return / continue แทน if-else หรือไม่?

Question 5

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

Question 6

ตัวอย่างแรกคือการใช้คำสั่งยาม จากWikipedia :

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

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

โดยทั่วไปแล้วจะต้องการสิ่งนี้:

void DoThis()
{
  if (guard1) return;
  if (guard2) return;
  ...
  if (guardN) return;

  DoThat();
}

ฉันคิดว่ามันสามารถอ่านได้มากกว่านี้:

void DoThis()
{
  if (guard1 && guard2 && guard3)
  {
    DoThat();
  }
}

Question 7

ไม่มีการลงโทษด้านประสิทธิภาพอย่างไรก็ตามส่วนที่สองของโค้ดสามารถอ่านได้มากกว่าและดูแลรักษาง่ายกว่า

Question 8

ในกรณีนี้ตัวอย่างที่สองของคุณคือโค้ดที่ดีกว่า แต่นั่นไม่เกี่ยวข้องกับการกลับมาจากฟังก์ชัน void เพียงเพราะว่าโค้ดที่สองนั้นตรงกว่า แต่การกลับมาจากฟังก์ชันโมฆะนั้นใช้ได้โดยสิ้นเชิง

Question 9

ไม่เป็นไรและไม่มี 'โทษประสิทธิภาพ' แต่ไม่เคยเขียนคำสั่ง 'if' โดยไม่มีวงเล็บ

เสมอ

if( foo ){
    return;
}

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

Question 10

ฉันจะไม่เห็นด้วยกับ whippersnappers รุ่นเยาว์ของคุณทั้งหมด

การใช้ผลตอบแทนกลางวิธีถือเป็นโมฆะหรืออย่างอื่นเป็นการปฏิบัติที่ไม่ดีด้วยเหตุผลที่มีการพูดชัดแจ้งอย่างชัดเจนเมื่อเกือบสี่สิบปีที่แล้วโดย Edsger W. "และดำเนินการต่อใน" Structured Programming "โดย Dahl, Dijkstra และ Hoare

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

"แถลงการณ์ของ GOTO ถือว่าเป็นอันตราย" และ "การเขียนโปรแกรมเชิงโครงสร้าง" เริ่มต้นการปฏิวัติ "การเขียนโปรแกรมเชิงโครงสร้าง" ในปี 1970 ทั้งสองส่วนนี้เป็นเหตุผลที่เรามี if-then-else, while-do และโครงสร้างการควบคุมที่ชัดเจนอื่น ๆ ในปัจจุบันและเหตุใดคำสั่ง GOTO ในภาษาระดับสูงจึงอยู่ในรายการสัตว์ใกล้สูญพันธุ์ (ความเห็นส่วนตัวของฉันคือพวกมันต้องอยู่ในรายชื่อพันธุ์ที่สูญพันธุ์)

เป็นที่น่าสังเกตว่า Message Flow Modulator ซึ่งเป็นซอฟต์แวร์ทางทหารชิ้นแรกที่เคยผ่านการทดสอบการยอมรับในการลองครั้งแรกโดยไม่มีการเบี่ยงเบนการสละสิทธิ์หรือ "ใช่ แต่" ใช้คำฟุ่มเฟือยเขียนด้วยภาษาที่ไม่มีแม้แต่ คำสั่ง GOTO

นอกจากนี้ยังควรค่าแก่การกล่าวถึงว่า Nicklaus Wirth เปลี่ยนความหมายของคำสั่ง RETURN ใน Oberon-07 ซึ่งเป็นเวอร์ชันล่าสุดของภาษาการเขียนโปรแกรม Oberon ทำให้เป็นส่วนต่อท้ายของการประกาศขั้นตอนการพิมพ์ (เช่นฟังก์ชัน) แทนที่จะเป็น คำสั่งปฏิบัติการในเนื้อหาของฟังก์ชัน ชี้แจงของเขาจากการเปลี่ยนแปลงกล่าวว่าเขาไม่ได้อย่างแม่นยำเพราะรูปแบบก่อนหน้านี้WASเป็นการละเมิดหลักการหนึ่งทางออกของการเขียนโปรแกรมโครงสร้าง

Question 11

ขณะใช้ยามโปรดปฏิบัติตามคำแนะนำบางประการเพื่อไม่ให้ผู้อ่านสับสน

ฟังก์ชันทำสิ่งหนึ่ง
ยามจะถูกนำมาใช้เป็นตรรกะแรกในฟังก์ชันเท่านั้น
unnestedส่วนหนึ่งที่มีฟังก์ชั่นของความตั้งใจหลัก

ตัวอย่าง

// guards point you to the core intent
void Remove(RayCastResult rayHit){

  if(rayHit== RayCastResult.Empty)
    return
    ;
  rayHit.Collider.Parent.Remove();
}

// no guards needed: function split into multiple cases
int WonOrLostMoney(int flaw)=>
  flaw==0 ? 100 :
  flaw<10 ? 30 :
  flaw<20 ? 0 :
  -20
;

Question 12

โยนข้อยกเว้นแทนที่จะไม่ส่งคืนอะไรเลยเมื่อวัตถุเป็นโมฆะเป็นต้น

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

แต่การกลับมาก่อนกำหนดไม่ใช่การปฏิบัติที่ไม่ดี