วิธีการที่ยาวนานนั้นไม่ดีเสมอไปหรือไม่? [ปิด]

64

ดังนั้นก่อนหน้านี้ฉันสังเกตเห็นความคิดเห็นบางอย่างเกี่ยวกับวิธีการที่ยาวนานว่าเป็นการฝึกฝนที่ไม่ดี

ฉันไม่แน่ใจว่าฉันเห็นด้วยเสมอว่าวิธีการที่ยาวนานนั้นไม่ดี (และต้องการความคิดเห็นจากผู้อื่น)

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

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

variable_1 = 0
variable_2 = 0
for object in queryset :
     if object.condition_condition_a and variable_2 > 0 :
     variable 1+= 1
     .....
     ...    
     . 
      more conditions to alter the variables

return queryset, and context

ตามทฤษฎีฉันควรแยกรหัสทั้งหมดออกเป็นวิธีที่เล็กลงเพื่อให้ฉันมีวิธีการดูว่ายาวที่สุดในหนึ่งหน้า

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

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

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

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

ปรับปรุง: ดูเหมือนว่าฉันถามคำถามนี้กว่าปีที่ผ่านมา

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

ก่อน:

#comment 1 
bit of (uncomplicated) code 1a  
bit of code 2a

#comment 2 
bit of code 2a
bit of code 2b
bit of code 2c

#comment 3
bit of code 3

ขณะนี้:

method_call_1
method_call_2
method_call_3

def method_1 
    bit of (uncomplicated) code 1a  
    bit of code 2a

def method_2 
    bit of code 2a
    bit of code 2b
    bit of code 2c

def method_3
    bit of code 3

readability methods

— wobbily_col
แหล่งที่มา

156

สัมบูรณ์ทั้งหมดไม่ถูกต้อง เสมอ.

— โจอาคิมซาวเออร์

30

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

— Joachim Sauer

4

@gnat: ว้าวการเรียงแบบแมนนวล (ผ่านตัวประมวลผลล่วงหน้า) ใน build-step นั้นจะเป็นทางออกที่ดีกว่าหรือไม่

— Joachim Sauer

11

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

— Chuu

2

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

— Carson63000

80

ไม่นานวิธีการที่ไม่เลวเสมอไป

ใน Book Code Completeจะมีการวัดว่าบางครั้งวิธีการที่ยาวกว่าจะเร็วกว่าและง่ายกว่าในการเขียนและไม่นำไปสู่ปัญหาการบำรุงรักษา

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

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

แก้ไข: เมื่อมีการแสดงความคิดเห็นฉันเพิ่มจุดที่น่าสนใจในคำตอบ ในความเป็นจริงฉันจะตรวจสอบตัวชี้วัดความซับซ้อนของฟังก์ชัน (NPATH, ความซับซ้อนของวงจรหรือ CRAP ที่ดียิ่งขึ้น)

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

— deadalnix
แหล่งที่มา

41

+1: "ไม่นานวิธีการไม่เลวเสมอไป" แต่พวกมันเกือบจะแย่เสมอ

— Binary Worrier

67

ร่างกายของวิธีการแบบยาวนั้นเป็นกลิ่นรหัสคลาสสิก: มันไม่ได้มีปัญหา แต่ก็เป็นข้อบ่งชี้ว่าอาจมีปัญหาอยู่ที่นั่น

— โจอาคิมซาวเออร์

6

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

— Daniel B

11

ฉันใช้ชื่อวิธีเพื่อลดความคิดเห็น ซึ่งบางครั้งนำไปสู่สิ่งต่าง ๆ เช่น "getSelectedNodeWithChildren" แต่เพื่อนร่วมงานของฉันบอกฉันเสมอว่ารหัสของฉันอ่านได้ง่าย ฉันยังพยายามหลีกเลี่ยงตัวย่อพวกเขาเขียนดี แต่อ่านไม่ค่อยดี

— K ..

4

@ da_b0uncer นั่นเป็นนโยบายที่ฉันติดตาม มันยากที่จะอ่านโค้ดมากกว่าที่จะเขียนมันดังนั้นความพยายามเป็นพิเศษเมื่อเขียนเพื่อให้โค้ดอ่านง่ายขึ้นจะจ่ายคืน

— deadalnix

55

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

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

แก้ไข - เพื่อนำสิ่งนั้นไปใช้ในมุมมองที่ต่างออกไปลองคิดดูว่ามันเป็นเช่นนี้: คุณจะอธิบายวิธีดังกล่าวให้กับสมาชิกทีมคนใหม่ได้อย่างไร? แน่นอนว่ามันมีโครงสร้างบางอย่างที่คุณสามารถสรุปตามแนวของ "ดีมันเริ่มต้นทำ A แล้ว B แล้วบางครั้ง C ฯลฯ " การมีวิธี "ภาพรวม" แบบสั้น ๆ ที่เรียกวิธีการอื่นทำให้โครงสร้างนี้ชัดเจน มันหายากเหลือเกินที่จะพบโค้ด 350 บรรทัดซึ่งไม่เป็นประโยชน์ สมองของมนุษย์ไม่ได้หมายถึงการจัดการกับรายการ 100s ของรายการที่ยาวเราจัดกลุ่มพวกเขา

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

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

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

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

— Daniel B
แหล่งที่มา

13

+1 สำหรับการไม่ตอบคำถามเสมอและมุ่งเน้นไปที่เนื้อสัตว์: วิธีการที่ยาวหรือไม่ดี ฉันคิดว่า OP กำลังมองหาการให้เหตุผลราวกับว่าสถานการณ์ของเขาเป็นกรณีที่มีความทันสมัย แต่โดยปกติแล้วเมื่อฉันได้ยินคนอธิบายถึงการปฏิบัติที่ไม่ดีของพวกเขาตามความจำเป็นสำหรับสถานการณ์ที่ไม่ธรรมดามันเป็นเพียงเพราะพวกเขาไม่พยายามอย่างหนัก สถานการณ์ที่ไม่ธรรมดานั้นเป็นเรื่องแปลกมากจริง ๆ แล้ววิธีการที่ยาวนานนั้นค่อนข้างน่าเศร้า

— จิมมี่ฮอฟฟา

2

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

— wobbily_col

1

@wobbily_col BTW หากคุณกำลังมองหาข้อความที่เขียนอย่างดีซึ่งมีเหตุผลในการใช้วิธีการที่สั้นกว่าอ่านบทแรก ๆ ของClean Codeซึ่งทำหน้าที่อธิบายได้ค่อนข้างดี

— Daniel B

5

@wobbily_col คุณพูดว่าต้องกระโดดไปรอบ ๆ มากเกินไปที่จะเข้าใจรหัสด้วยวิธีการต่าง ๆ ที่สับสนฉันคิดว่าจุดที่ขาดหายไปที่นี่คือความสำคัญของการตั้งชื่อ หากวิธีการตั้งชื่อไว้อย่างดีคุณไม่จำเป็นต้องมองหาวิธีที่จะทำวิธีการโทรควรจะเข้าใจได้อย่างสมบูรณ์โดยไม่ต้องมีความรู้พื้นฐานเกี่ยวกับวิธีการโทรที่กำลังทำตัวอย่างเช่นคุณเคยใช้someVar.toString()และรู้สึกว่า คุณต้องการที่จะเห็นรหัสของ toString เพื่อรู้ว่ามันกำลังทำอะไร? คุณเพิ่งอ่านมันผ่านมาเพราะวิธีการตั้งชื่อที่ดี

— จิมมี่ฮอฟฟา

4

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

— KL

28

วิธีการที่ยาวมักจะไม่ดี แต่บางครั้งก็ดีกว่าทางเลือกอื่น

— Telastyn
แหล่งที่มา

5

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

— ริ้น

9

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

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

— Melebius
แหล่งที่มา

7

วิธีการที่ยาวนานไม่ได้เลวร้ายเสมอไป พวกเขามักจะเป็นสัญญาณว่าอาจมีปัญหา

ในระบบที่ฉันใช้งานเรามีวิธีครึ่งโหลหรือมากกว่านั้นที่มีความยาวมากกว่า 10,000 บรรทัด ปัจจุบันมีความยาว 54,830 บรรทัด และมันก็โอเค

ฟังก์ชั่นยาวที่น่าขันเหล่านี้ง่ายมากและมีการสร้างอัตโนมัติ สัตว์ประหลาดตัวยาว 54,830 เส้นตัวใหญ่นั้นมีข้อมูลการเคลื่อนไหวขั้วโลกทุกวันตั้งแต่วันที่ 1 มกราคม 1962 ถึง 10 มกราคม 2012 (การเปิดตัวครั้งสุดท้ายของเรา) นอกจากนี้เรายังปล่อยขั้นตอนที่ผู้ใช้ของเราสามารถอัปเดตไฟล์ที่สร้างอัตโนมัติ ไฟล์ต้นฉบับนั้นมีข้อมูลการเคลื่อนไหวแบบโพลาร์จากhttp://data.iers.org/products/214/14443/orig/eopc04_08_IAU2000.62-nowแปลอัตโนมัติเป็น C ++

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

— David Hammen
แหล่งที่มา

6

"หนึ่งคำสั่งการมอบหมายหลังจากนั้น" ... ฉันจะเรียกว่า "ไฟล์ข้อมูล" ทำไมรหัส

— โจอาคิมซาวเออร์

3

@JoachimSauer - เนื่องจากการแยกไฟล์ข้อมูลขนาดใหญ่ในขณะทำงานในการตั้งค่า Monte Carlo เป็นความคิดที่ไม่ดี เป็นความคิดที่แย่มาก ๆ

— David Hammen

4

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

— Javier

3

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

— David Hammen

7

+1 เรื่องราวที่น่าสนใจ รหัสที่สร้างขึ้นไม่ได้เป็นซอร์สโค้ดแน่นอนจริงๆดังนั้นเราจึงสามารถยืนยันได้ว่านี่จะไม่ 'ทำลาย' กฎ หนึ่งถือว่าตัวสร้างโค้ดนั้นมีวิธีสั้น ๆ ที่ดี

— jk

7

สมมติว่ามีวิธีที่ดีและไม่ดีในการเลิกใช้วิธีการที่ยาวนาน การที่ต้อง "[เก็บ] วิธีการที่อยู่ด้านนอกสุดในหัวของคุณ" เป็นสัญญาณว่าคุณไม่ได้ทำลายมันในวิธีที่เหมาะสมที่สุดหรือวิธีการที่คุณตั้งชื่อไม่ดี ในทางทฤษฎีมีหลายกรณีที่วิธีการแบบยาวดีกว่า ในทางปฏิบัติมันหายากมาก หากคุณไม่สามารถหาวิธีทำให้วิธีที่สั้นกว่าสามารถอ่านได้ให้คนอื่นตรวจสอบรหัสของคุณและขอให้พวกเขาหาแนวคิดในการย่อวิธีให้สั้นลง

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

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

— Karl Bielefeldt
แหล่งที่มา

1

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

— Tjaart

+1 สำหรับ "ต้อง" [เก็บ] วิธีการที่อยู่ด้านนอกสุดในหัวของคุณ "เป็นสัญญาณว่าคุณไม่ได้ทำลายมันในวิธีที่เหมาะสมที่สุด"

— Michael Shaw

4

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

— ฤLlษีลามะ
แหล่งที่มา

34

มีโปรแกรมเมอร์อย่างน้อยสองคนที่เกี่ยวข้อง: "คุณ" และ "คุณสามสัปดาห์นับจากนี้"

— Joachim Sauer

3

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

แม่นยำวิธีการของคุณควรเน้นไปที่งาน perforimng 1 เท่านั้น

และหากจำเป็นต้องเรียกใช้วิธีอื่นหรือด้วยเหตุผลบางอย่างให้ทำเช่นนั้นต่อไปกับวิธีที่คุณเขียนไปแล้ว นอกจากนี้สำหรับ pruposes ที่อ่านง่ายคุณสามารถเพิ่มความคิดเห็นได้ นักเขียนโปรแกรมใช้ความคิดเห็นหลายบรรทัด (/ ** / ใน C, C ++, C # และ Java) สำหรับคำอธิบายวิธีการและใช้ความคิดเห็นบรรทัดเดียว (// ใน C, C ++, C # และ Java) นอกจากนี้ยังมีเครื่องมือเอกสารที่ดีพร้อมใช้งานสำหรับการอ่านรหัสที่มากขึ้น (เช่นJavaDoc ) คุณยังสามารถดูความคิดเห็นจาก XMLหากคุณเป็นนักพัฒนา. Net

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

— Maxood
แหล่งที่มา

หรือที่เรียกว่า "ฟังก์ชั่นควรทำสิ่งหนึ่งสิ่ง"

— lorddev

3

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

มีการสนทนาสั้น ๆ ที่ยอดเยี่ยมใน Code Complete 2 เกี่ยวกับความยาวของรูทีน

ความยาวสูงสุด 497 ที่ดีที่สุดในทางทฤษฎีมักถูกอธิบายว่าเป็นหนึ่งหรือสองหน้าของรายการโปรแกรม 66 ถึง 132 บรรทัด โปรแกรมที่ทันสมัยมีแนวโน้มที่จะมีปริมาณของรูทีนที่สั้นมากผสมกับรูทีนที่ยาวกว่าเล็กน้อย

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

หากคุณต้องการเขียนกิจวัตรเกินกว่า 200 บรรทัดให้ระวัง ไม่มีการศึกษาใดที่รายงานว่าลดค่าใช้จ่ายลดอัตราความผิดพลาดหรือทั้งสองอย่างด้วยกิจวัตรที่มีขนาดใหญ่กว่าซึ่งแตกต่างกันระหว่างขนาดที่ใหญ่กว่า 200 บรรทัดและคุณจะต้องเผชิญกับขีด จำกัด สูงสุดของความเข้าใจ 536 ข้อ จำกัด ต่อ se

— Sarat
แหล่งที่มา

2

โหวตอีกครั้งว่ามันผิดทุกครั้ง ฉันพบสองกรณีพื้นฐานที่เป็นคำตอบที่เหมาะสม แต่:

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

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

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

— Loren Pechtel
แหล่งที่มา

1

กระบวนการ 50 ขั้นตอนอาจสรุปได้ในหลาย ๆ ถังผ่าน ขั้นตอนที่ 1 - 9 เป็นการตรวจสอบพารามิเตอร์ดังนั้นสร้างวิธีใหม่ที่เรียกว่าการตรวจสอบพารามิเตอร์ (ฉันแน่ใจว่ามีบางตัวอย่างที่ไม่สามารถทำได้ฉันจะสนใจดู)

— sixtyfootersdude

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

— Loren Pechtel

& sixtyfootersdude: มันวิเศษมากที่คุณรู้รหัสที่คุณไม่เคยเห็นและปรับปรุงมัน

— gnasher729

2

ฉันต้องการพูดถึงตัวอย่างที่คุณให้:

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

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

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

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

— phasetwenty
แหล่งที่มา

2

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

function nextSlide() {
  var content = getNextSlideContent();
  hideCurrentSlide();
  var newSlide = createSlide(content);
  setNextSlide(newSlide);
  showNextSlide();
}

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

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

เมื่อฉันสร้างวิธีการฉันมักจะจบลงด้วยการแบ่งพวกเขาออกเป็นวิธีเล็ก ๆ เพื่อแบ่งและเอาชนะกลยุทธ์ วิธีการเช่น

   if (hasMoreRecords()) { ... }

สามารถอ่านได้ง่ายกว่า

if (file.isOpen() && i < recordLimit && currentRecord != null) { ... }

ขวา?

ฉันเห็นด้วยเกี่ยวกับข้อความที่ไม่ถูกต้องและยอมรับด้วยว่าวิธีการที่ยาวมักจะไม่ดี

— Tjaart
แหล่งที่มา

1

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

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

— Michael Brown
แหล่งที่มา

0

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

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

— จางไป
แหล่งที่มา

ช่วยลดรหัสสิ่งที่ ?

— Avner Shahar-Kashtan

@ AvnerShahar-Kashtan เขาอาจหมายถึง "การทำสำเนา" :-)

— PéterTörök

0

ไม่ใช่วิธีการยาว ๆ ที่เป็นการฝึกฝนที่ไม่ดี แต่ทิ้งไว้อย่างนั้นไม่ดี

ฉันหมายความว่าการกระทำจริงของการปรับตัวอย่างของคุณจาก:

varaible_1 = 0
variable_2 = 0
for object in queryset :
     if object.condition_condition_a and variable_2 > 0 :
     variable 1+= 1
     .....
     ...    
     . 
      more conditions to alter the variables

return queryset, and context

ไปยัง

Status status = new Status();
status.variable1 = 0;
status.variable2 = 0;
for object in queryset :
     if object.condition_condition_a and status.variable2 > 0 :
     status.variable1 += 1
     .....
     ...    
     . 
      more conditions to alter the variables (status)

return queryset, and context

แล้วไปที่

class Status {
    variable1 = 0;
    variable2 = 0;

    void update(object) {
        if object.condition_condition_a and variable2 > 0 {
            variable1 += 1
        }
    }
};

Status status = new Status();
for object in queryset :
     status.update(object);
     .....
     ...    
     . 
      more conditions to alter the variables (status)

return queryset, and context

ตอนนี้คุณก็พร้อมแล้วที่จะไม่ใช่แค่วิธีที่สั้นกว่านี้ แต่เป็นวิธีที่ใช้ได้และเข้าใจได้มากกว่า

— OldCurmudgeon
แหล่งที่มา

0

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

foreach(var x in y)
{
    //do ALL the things
    //....
}

และเนื้อความของลูปไม่ได้แปลเป็นภาษาท้องถิ่นอย่างมาก (เช่นคุณสามารถส่งได้น้อยกว่า 4 พารามิเตอร์) จากนั้นควรแปลงเป็น:

foreach(var x in y)
{
    DoAllTheThings(x);
}
...
void DoAllTheThings(object x)
{
    //do ALL the things
    //....
}

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

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

— Earlz
แหล่งที่มา

0

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

ประการที่สองเมื่อพูดถึงฟังก์ชั่น / ขั้นตอน:

void setDataValueAndCheckForRange(Data *data) {/*code*/}

เป็นวิธีที่ดีถ้าจะตรวจสอบช่วงของ "ข้อมูล" เท่านั้น มันเป็นวิธีการที่ไม่ดีเมื่อช่วงเดียวกันใช้สำหรับฟังก์ชั่นหลาย ๆ อย่าง (ตัวอย่างของรหัสที่ไม่ดี):

void setDataValueAndCheckForRange(Data *data){ /*code */}
void addDataValuesAndCheckForRange(Data *result, Data *d1, Data *d2){ /*code*/}
void subDataValuesAndCheckForRange(Data *result, Data *d1, Data *d2){ /*code*/}
void mulDataValuesAndCheckForRange(Data *result, Data *d1, Data *d2){ /*code*/}

สิ่งนี้จะต้องได้รับการปรับสภาพใหม่เพื่อ:

bool isWithinRange(Data *d){ /*code*/ }
void setDataValue(Data *d) {/*code*/ if(isWithinRange(d)){/*continue*/}else{/*warn/abort*/} 
void addDataValue(Data *d, Data *d1, Data *d2) {/*code*/ if(isWithinRange(d)){/*continue*/}else{/*warn/abort*/} 
void subDataValue(Data *d, Data *d1, Data *d2) {/*code*/ if(isWithinRange(d)){/*continue*/}else{/*warn/abort*/} 
void mulDataValue(Data *d, Data *d1, Data *d2) {/*code*/ if(isWithinRange(d)){/*continue*/}else{/*warn/abort*/}

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

อ้างถึง: ภูเขาแห่งนั้นประกอบไปด้วยเม็ดเล็ก ๆ ของโลก มหาสมุทรประกอบด้วยน้ำหยดเล็ก ๆ .. (- Sivananda)

— Aniket Inge
แหล่งที่มา

0

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

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

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

— Stephen Swensen
แหล่งที่มา

ในภาษาที่ใช้งานได้ แต่วิธีการแบบยาวนั้นใช้กันน้อยกว่ามาก

— itsbruce