การใช้ goto คุ้มค่าไหม?

gotoเกือบจะท้อแท้ในระดับสากล การใช้คำสั่งนี้คุ้มค่าหรือไม่?

มีการพูดคุยกันหลายครั้งใน Stack Overflow และ Chris Gillum สรุปการใช้ที่เป็นไปได้ของgoto :

ออกจากฟังก์ชันอย่างหมดจด

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

กำลังออกจากลูปซ้อนกัน

หากคุณอยู่ในลูปซ้อนกันและต้องการแยกลูปออกทั้งหมดลูปสามารถทำให้สิ่งนี้สะอาดและง่ายกว่าการใช้คำสั่ง break และ if-checks

การปรับปรุงประสิทธิภาพระดับต่ำ

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

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

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

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

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

รหัสอื่นที่มีโครงสร้างเทียบเท่ากับโดเมนปัญหามีแนวโน้มที่จะอ่านและบำรุงรักษาได้ง่ายกว่า

ไม่มีกรณีที่จำเป็นต้องมีคำสั่ง goto อย่างแน่นอน (มีทฤษฎีบทเกี่ยวกับผลกระทบนั้น) แต่มีบางกรณีที่สามารถเป็นวิธีแก้ปัญหาที่แย่ที่สุดได้ กรณีเหล่านี้แตกต่างจากภาษาเป็นภาษาขึ้นอยู่กับสิ่งที่สร้างระดับสูงกว่ารองรับภาษา

ยกตัวอย่างเช่นใน C ฉันเชื่อว่ามีสามสถานการณ์พื้นฐานที่มีการข้ามไปเหมาะสม

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

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

การใช้งานหลักของ goto ในภาษาสมัยใหม่ที่สมเหตุสมผล (ภาษาที่รองรับหาก / else และ loops) คือการจำลองโครงสร้างโฟลว์การควบคุมที่ขาดหายไปจากภาษา

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

Java ได้พยายาม“ แก้ไข” ปัญหานี้โดยไม่อนุญาตgotoทั้งหมด อย่างไรก็ตาม Java ช่วยให้คุณใช้returnภายในfinallyบล็อกและทำให้เกิดข้อยกเว้นเพื่อการกลืนโดยไม่ตั้งใจ ปัญหาเดียวกันยังคงมีอยู่: คอมไพเลอร์ไม่ทำงาน การลบออกgotoจากภาษายังไม่ได้รับการแก้ไข

ใน C #, gotoคือเป็นที่ปลอดภัยbreak, continue, และtry/catch/finally returnมันไม่อนุญาตให้คุณใช้ตัวแปรที่ไม่กำหนดค่าเริ่มต้นมันจะไม่ยอมให้คุณกระโดดออกจากบล็อกในที่สุด ฯลฯ คอมไพเลอร์จะบ่น นี่เป็นเพราะมันแก้ปัญหาที่แท้จริงซึ่งเป็นเหมือนที่ฉันบอกว่าการควบคุมการไหลไร้สาระ gotoไม่ได้ยกเลิกการวิเคราะห์ที่ได้รับมอบหมายอย่างชัดเจนและการตรวจสอบคอมไพเลอร์ที่สมเหตุสมผลอื่น ๆ อย่างน่าอัศจรรย์

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

แน่นอนว่าข้อความที่มีข้อความกำกับของ Java นั้นbreakทำสิ่งเดียวกัน แต่ไม่อนุญาตให้คุณข้ามไปยังจุดใดก็ได้ในรหัสซึ่งแก้ปัญหาได้อย่างเรียบร้อยโดยไม่ยอมให้สิ่งgotoชั่วร้าย

ความท้อแท้ส่วนใหญ่เกิดขึ้นในรูปแบบของ "ศาสนา" ที่ได้รับการสร้างขึ้นมาโดยพระเจ้า Djikstra ซึ่งเป็นแรงบันดาลใจในช่วงต้นยุค 60 เกี่ยวกับพลังที่ไม่สามารถแยกแยะได้ดังนี้

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

สิ่งนี้ไม่มีอะไรเกี่ยวข้องกับgotoคำแถลงของภาษาสมัยใหม่ซึ่งมีอยู่เพียงเพื่อสนับสนุนการสร้างโครงสร้างรหัสอื่น ๆ นอกเหนือจากภาษาที่ให้ไว้

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

คุณสามารถอ้างถึงคำตอบนี้เพื่อให้ทราบว่าแม้แต่โค้ดที่ไม่ได้ใช้ goto สามารถอ่านไม่ได้ ปัญหาไม่ได้เป็นของตัวเอง แต่ใช้ไม่ได้ผล

ฉันสามารถเขียนโปรแกรมทั้งหมดโดยไม่ต้องใช้เพียงif forแน่นอนว่ามันจะไม่สามารถอ่านได้ดีมีลักษณะเงอะงะและซับซ้อนโดยไม่จำเป็น

forแต่ปัญหาก็คือไม่ได้ ฉันเอง.

สิ่งที่ชอบbreak, continue, throw, bool needed=true; while(needed) {...}ฯลฯ จะสังเกตมากกว่าสวมหน้ากาก gotoที่จะหลบหนีออกไปจากดาบของหัวรุนแรง Djikstrarian ที่ -50 ปีหลังจากการประดิษฐ์ของ laguages- สมัยใหม่ยังคงต้องการที่นักโทษของพวกเขา พวกเขาลืมสิ่งที่ Djikstra พูดถึงพวกเขาจำได้แค่ชื่อโน้ตของเขาเท่านั้น (GOTO ถือว่าเป็นอันตรายและไม่ใช่แม้แต่ชื่อของเขา: มันเปลี่ยนโดยบรรณาธิการ) และตำหนิและทุบตีทุบตีและตำหนิทุกโครงสร้างที่มี 4 ตัวอักษรเรียงตามลำดับ

ถึงปี 2011: ถึงเวลาที่จะเข้าใจว่าgotoการไม่ปฏิบัติตามGOTOคำแถลง Djikstra นั้นเป็นเรื่องที่น่าสนใจ

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

ถ้า gotos (ในพื้นที่) เป็นอันตรายต่อความสามารถในการอ่านอย่างมีนัยสำคัญโดยทั่วไปแล้วมันเป็นสัญญาณว่าฟังก์ชั่นที่มี goto นั้นซับซ้อนเกินไป

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

ฉันคิดว่าปัญหาทั้งหมดนี้เป็นกรณีของการเห่าต้นไม้ผิด

GOTO เช่นนั้นดูเหมือนจะไม่เป็นปัญหาสำหรับฉัน แต่มันมักจะเป็นอาการของบาปจริง: รหัสสปาเก็ตตี้

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

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

ใช่ goto สามารถใช้เพื่อให้ได้รับประโยชน์จากประสบการณ์ของผู้พัฒนา: http://adamjonrichardson.com/2012/02/06/long-live-the-goto-statement/

อย่างไรก็ตามเช่นเดียวกับเครื่องมืออันทรงพลังใด ๆ (พอยน์เตอร์การสืบทอดหลาย ๆ แบบ) ต้องมีระเบียบวินัยในการใช้งาน ตัวอย่างที่มีให้ในลิงค์ใช้ PHP ซึ่ง จำกัด การใช้ goto construct ให้เป็นฟังก์ชัน / วิธีการเดียวกันและปิดการใช้งานความสามารถในการข้ามไปยังบล็อกควบคุมใหม่ (เช่นวนรอบคำสั่งสลับ ฯลฯ )

ขึ้นอยู่กับภาษา มันยังคงใช้กันอย่างแพร่หลายในการเขียนโปรแกรม Cobol เช่น ฉันยังทำงานกับอุปกรณ์ Barionet 50 ซึ่งภาษาการเขียนโปรแกรมเฟิร์มแวร์เป็นภาษาเบสิกพื้นฐานที่แน่นอนว่าคุณต้องใช้ Goto

ฉันจะบอกว่าไม่มี หากคุณพบว่าจำเป็นต้องใช้ GOTO ฉันจะเดิมพันว่ามีความจำเป็นต้องออกแบบรหัสใหม่

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

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