`การแตก 'และ` การปฏิบัติการ' ที่แย่ ๆ

เจ้านายของฉันพูดถึงอย่างเมินเฉยว่าโปรแกรมเมอร์ที่ไม่ดีใช้breakและcontinueวนซ้ำ

ฉันใช้มันตลอดเวลาเพราะมันสมเหตุสมผล ให้ฉันแสดงแรงบันดาลใจ:

function verify(object) {
    if (object->value < 0) return false;
    if (object->value > object->max_value) return false;
    if (object->name == "") return false;
    ...
}

จุดที่นี่คือก่อนอื่นฟังก์ชันตรวจสอบว่าเงื่อนไขถูกต้องจากนั้นดำเนินการฟังก์ชันการทำงานจริง IMO เช่นเดียวกับลูป:

while (primary_condition) {
    if (loop_count > 1000) break;
    if (time_exect > 3600) break;
    if (this->data == "undefined") continue;
    if (this->skip == true) continue;
    ...
}

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

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

เมื่อใช้ในช่วงกลางของบล็อกโดยมีรหัสอยู่รอบ ๆ พวกมันทำตัวเหมือนกับดักที่ซ่อนอยู่ดังนั้นมันจึงไม่ดี

คุณสามารถอ่านการเขียนโปรแกรมแบบมีโครงสร้างของ Donald Knuth ในปี 1974 โดยใช้คำสั่ง goซึ่งเขากล่าวถึงการใช้งานต่าง ๆ ของสิ่งgo toที่เป็นที่ต้องการในเชิงโครงสร้าง พวกเขารวมถึงเทียบเท่าbreakและcontinueงบ (การใช้งานจำนวนมากgo toในนั้นได้รับการพัฒนาเป็นโครงสร้างที่ จำกัด มากขึ้น) เจ้านายของคุณเป็นคนประเภทที่เรียก Knuth ว่าเป็นโปรแกรมเมอร์ที่ไม่ดีหรือไม่?

(ตัวอย่างที่ให้ความสนใจฉันโดยทั่วไปแล้วbreakและcontinueไม่ชอบโดยคนที่ชอบหนึ่งรายการและหนึ่งทางออกจากชิ้นส่วนของรหัสใด ๆ และคนประเภทนั้นก็ขมวดคิ้วในหลายreturnงบ)

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

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

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

ปัญหาเหล่านี้ได้รับการแก้ไขใน "รหัสสะอาด" โดย Robert C. Martin และใน "Refactoring" โดย Martin Fowler

โปรแกรมเมอร์ที่ไม่ดีสามารถพูดได้อย่างสมบูรณ์ (เช่นเดียวกับ Sith) โปรแกรมเมอร์ที่ดีใช้วิธีการแก้ปัญหาที่ชัดเจนที่สุด ( ทุกสิ่งอื่น ๆ เหมือนกัน )

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

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

คนส่วนใหญ่คิดว่าเป็นความคิดที่ไม่ดีเพราะพฤติกรรมไม่สามารถคาดเดาได้ง่าย หากคุณอ่านรหัสและเห็นwhile(x < 1000){}ว่าคุณคิดว่ามันจะทำงานจนกว่า x> = 1,000 ... แต่ถ้ามีตัวแบ่งอยู่ตรงกลางนั่นก็ไม่ถือว่าเป็นจริงดังนั้นคุณจึงไม่ไว้ใจ วนลูป ...

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

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

ใช่คุณสามารถ [เขียน] โปรแกรมโดยไม่มีคำสั่ง break (หรือส่งคืนจากตรงกลางของลูปซึ่งทำสิ่งเดียวกัน) แต่คุณอาจต้องแนะนำตัวแปรเพิ่มเติมและ / หรือการทำสำเนาโค้ดซึ่งโดยทั่วไปจะทำให้โปรแกรมเข้าใจยากขึ้น Pascal (ภาษาการเขียนโปรแกรม) นั้นแย่มากโดยเฉพาะอย่างยิ่งสำหรับโปรแกรมเมอร์มือใหม่ด้วยเหตุผลนั้น หัวหน้าของคุณต้องการให้คุณเขียนโปรแกรมในโครงสร้างการควบคุมของ Pascal หาก Linus Torvalds อยู่ในรองเท้าของคุณเขาอาจแสดงนิ้วกลางของเจ้านายคุณ!

มีผลลัพธ์ทางวิทยาศาสตร์คอมพิวเตอร์ที่เรียกว่าลำดับชั้นของโครงสร้างการควบคุมของ Kosaraju ซึ่งมีอายุย้อนไปถึงปี 1973 และมีการกล่าวถึงในบทความที่มีชื่อเสียง (เพิ่มเติม) ของ Knuth ใน gotos จากปี 1974 (เอกสารฉบับนี้ Knuth ได้รับการแนะนำข้างต้นแล้วโดย David Thornley .) สิ่งที่สเราโคสาราจูพิสูจน์แล้วในปี 1973 ก็คือว่ามันเป็นไปไม่ได้ที่จะเขียนโปรแกรมทั้งหมดที่มีการแบ่งหลายระดับความลึกของnลงในโปรแกรมที่มีความลึกแบ่งน้อยกว่าnโดยไม่ต้องแนะนำตัวแปรเสริม แต่สมมุติว่านั่นเป็นเพียงผลลัพธ์ทางทฤษฎีเท่านั้น (เพียงเพิ่มตัวแปรพิเศษสองสามอย่าง! แน่นอนคุณสามารถทำเช่นนั้นเพื่อเอาใจเจ้านายของคุณ ... )

สิ่งที่สำคัญกว่าจากมุมมองด้านวิศวกรรมซอฟต์แวร์คือกระดาษ 1995 ล่าสุดโดย Eric S. Roberts บรรดาศักดิ์Loop Exits และ Programming แบบมีโครงสร้าง: เปิดการอภิปรายอีกครั้ง ( http://cs.stanford.edu/people/eroberts/papers/SIGCSE-) 1995 / LoopExits.pdf ) โรเบิร์ตส์สรุปการศึกษาเชิงประจักษ์หลายครั้งโดยคนอื่นก่อนเขา ตัวอย่างเช่นเมื่อกลุ่มนักเรียนประเภท CS101 ถูกขอให้เขียนรหัสสำหรับฟังก์ชั่นที่ใช้การค้นหาตามลำดับในอาเรย์ผู้เขียนของการศึกษากล่าวว่าต่อไปนี้เกี่ยวกับนักเรียนที่ใช้ตัวแบ่ง / return / goto เพื่อออกจาก วนลูปการค้นหาตามลำดับเมื่อพบองค์ประกอบ:

ฉันยังไม่พบคนเดียวที่พยายามใช้โปรแกรมโดยใช้ [ลักษณะนี้] ที่สร้างโซลูชันที่ไม่ถูกต้อง

โรเบิร์ตก็บอกว่า:

นักเรียนที่พยายามแก้ปัญหาโดยไม่ใช้ผลตอบแทนที่ชัดเจนจาก for for fared ก็ดีน้อยกว่ามาก: มีนักเรียนเพียงเจ็ดจาก 42 คนที่พยายามใช้กลยุทธ์นี้เพื่อจัดการกับวิธีแก้ไขที่ถูกต้อง ตัวเลขดังกล่าวแสดงถึงอัตราความสำเร็จน้อยกว่า 20%

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

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

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

ตัวอย่างที่คุณให้ไม่จำเป็นต้องหยุดพักหรือดำเนินต่อไป:

while (primary-condition AND
       loop-count <= 1000 AND
       time-exec <= 3600) {
   when (data != "undefined" AND
           NOT skip)
      do-something-useful;
   }

'ปัญหา' ของฉันที่มี 4 บรรทัดในตัวอย่างของคุณคือพวกเขาทั้งหมดอยู่ในระดับเดียวกัน แต่พวกเขาทำสิ่งที่แตกต่าง: บางตัวแบ่งบางส่วนดำเนินการต่อ ... คุณต้องอ่านแต่ละบรรทัด

ในแนวทางที่ซ้อนกันของฉันยิ่งคุณเข้าไปมากเท่าไหร่รหัสก็จะยิ่งมีประโยชน์มากขึ้นเท่านั้น

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

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

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

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

แต่การใช้คำสั่งเช่นbreakและcontinueจำเป็นอย่างยิ่งในทุกวันนี้และไม่ถือว่าเป็นการฝึกเขียนโปรแกรมที่ไม่ดีเลย

และยังไม่ยากที่จะทำความเข้าใจในการควบคุมการไหลในการใช้งานและbreak continueในโครงสร้างเช่นคำสั่งเป็นอย่างที่จำเป็นswitchbreak

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

บางส่วนความยากลำบากนี้สะท้อนให้เห็นถึงความสามารถในการคิดเหตุผลเกี่ยวกับรหัสของคุณ

ตรงไปตรงมารหัสที่สองของคุณไม่ชัดเจน มันทำอะไรอยู่? ทำต่อไป 'ทำต่อ' หรือทำต่อไป? ฉันไม่รู้. อย่างน้อยตัวอย่างแรกของคุณชัดเจน

ฉันจะแทนที่ข้อมูลโค้ดที่สองของคุณด้วย

while (primary_condition && (loop_count <= 1000 && time_exect <= 3600)) {
    if (this->data != "undefined" && this->skip != true) {
        ..
    }
}

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

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

ในบันทึกด้านข้าง ฉันไม่ต้องการเริ่มการสนทนาทางศาสนาที่นี่ แต่คุณสามารถปรับโครงสร้างรหัสของคุณให้อ่านง่ายขึ้นเช่นนี้:

while (primary_condition) {
    if (loop_count > 1000) || (time_exect > 3600) {
        break;
    } else if ( ( this->data != "undefined") && ( !this->skip ) ) {
       ... // where the real work of the loop happens
    }
}

เมื่อทราบอีกด้านหนึ่ง

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

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

สำหรับ "break" แยกลูปออกเป็นวิธีแยกต่างหากโดยแทนที่ "break" ด้วย "return"

หากวิธีการแยกต้องการอาร์กิวเมนต์จำนวนมากนั่นเป็นข้อบ่งชี้ในการแยกคลาส - รวบรวมไว้ในวัตถุบริบท

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

ตราบใดที่มันไม่ได้ถูกใช้เป็น goto ที่ปลอมตัวเหมือนในตัวอย่างต่อไปนี้:

do
{
      if (foo)
      {
             /*** code ***/
             break;
      }

      if (bar)
      {
             /*** code ***/
             break;
      }
} while (0);

ฉันสบายดีกับพวกเขา (ตัวอย่างที่เห็นในรหัสการผลิต meh)

ฉันไม่ชอบสไตล์เหล่านี้ นี่คือสิ่งที่ฉันต้องการ:

function verify(object)
{
    if not (object->value < 0) 
       and not(object->value > object->max_value)
       and not(object->name == "") 
       {
         do somethign important
       }
    else return false; //probably not necessary since this function doesn't even seem to be defined to return anything...?
}

ฉันไม่ชอบที่returnจะยกเลิกฟังก์ชั่น returnมันรู้สึกเหมือนการละเมิดของ

การใช้งานbreakยังไม่ชัดเจนในการอ่าน

ยังดีกว่า:

notdone := primarycondition    
while (notDone)
{
    if (loop_count > 1000) or (time_exect > 3600)
    {
       notDone := false; 
    }
    else
    { 
        skipCurrentIteration := (this->data == "undefined") or (this->skip == true) 

        if not skipCurrentIteration
        {
           do something
        } 
        ...
    }
}

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

(รหัสทั้งหมดข้างต้นเป็นรหัสหลอก)

ไม่มันเป็นวิธีในการแก้ปัญหาและมีวิธีอื่นในการแก้ปัญหา

ภาษากระแสหลักจำนวนมากในปัจจุบัน (Java, .NET (C # + VB), PHP, เขียนของคุณเอง) ใช้ "break" และ "Continue" เพื่อข้ามลูป พวกเขาทั้งสองประโยค "โครงสร้าง goto"

ปราศจากพวกเขา:

String myKey = "mars";

int i = 0; bool found = false;
while ((i < MyList.Count) && (not found)) {
  found = (MyList[i].key == myKey);
  i++;   
}
if (found)
  ShowMessage("Key is " + i.toString());
else
  ShowMessage("Not found.");

กับพวกเขาเหล่านั้น:

String myKey = "mars";

for (i = 0; i < MyList.Count; i++) {
  if (MyList[i].key == myKey)
    break;
}
ShowMessage("Key is " + i.toString());

โปรดทราบว่ารหัส "ตัวแบ่ง" และ "ต่อ" จะสั้นกว่าและมักจะเปลี่ยนเป็น "ในขณะที่" ประโยคเป็น "สำหรับ" หรือ "foreach" ประโยค

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

ที่จริงฉันทำงานในบางโครงการซึ่งเป็นข้อบังคับในการใช้ประโยคเหล่านั้น

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

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

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

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

for (var i = 0; i < collection.Count; i++)
{
    if (!Predicate(item)) continue;
    if (i >= 100) break; // at first I used a > here which is a bug. another good thing about the more declarative style!

    DoStuff(item);
}

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

foreach (var item in collection.Where(Predicate).Take(100))
    DoStuff(item);

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

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

Code Completeมีส่วนที่ดีเกี่ยวกับการใช้gotoและผลตอบแทนหลายรายการจากรูทีนหรือลูป

โดยทั่วไปแล้วการปฏิบัติไม่ใช่เรื่องเลวร้าย breakหรือcontinueบอกสิ่งที่เกิดขึ้นต่อไป และฉันเห็นด้วยกับสิ่งนี้

Steve McConnell (ผู้เขียน Code Complete) ใช้ตัวอย่างเกือบเหมือนกันกับคุณเพื่อแสดงข้อดีของการใช้gotoคำสั่งต่างๆ

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