อะไรคือความยาวสูงสุดที่ดีของฟังก์ชั่น [ปิด]

43

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

เนื่องจากเป็นหัวข้อที่มีความคิดเห็นสูงโปรดสำรองข้อมูลการอ้างสิทธิ์ด้วยข้อมูลบางส่วน

programming-practices coding-standards

— Peter Mortensen
แหล่งที่มา

5

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

— CaffGeek

4

เพียร์ของคุณบอกคุณหลังจากตรวจสอบรหัส

— ริ้น

12

ความยาวสูงสุดควรเป็น 17

— ThomasX

1

คิดว่าในโซลิด

— Kris Krause

1

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

— CodesInChaos

46

ตั้งแต่ฉันลงมือบนแร็คเก็ตบ้านี้ในปี 1970 ฉันได้เห็นโมดูลหนึ่งเดียวที่จำเป็นต้องมีมากกว่าหนึ่งหน้าพิมพ์ (ประมาณ 60 บรรทัด) ฉันได้เห็นโมดูลมากมายที่ยาวกว่านี้

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

ส่วนหนึ่งของปัญหาดูเหมือนว่าผู้เขียนโปรแกรมสมัยนี้ไม่ได้รับการสอนให้ทำสิ่งต่างๆ

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

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

— John R. Strohm
แหล่งที่มา

3

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

— Shog9

1

@นาย. CRT: ข้อจำกัดความยาวในการประยุกต์ใช้ FORTH แบบบล็อกเชิงเชิงบล็อก ลักษณะการโต้ตอบของ FORTH ส่วนใหญ่จะช่วยได้โดยการสนับสนุนโมดูลขนาดเล็กและการทดสอบอย่างรวดเร็วของโมดูลเหล่านั้น D85 ซึ่งเป็นไฟล์ FORTH ไม่ได้บังคับใช้การทำให้เป็นโมดูลและฉันเห็นคนที่เล่นกับ D85 เขียนจำนวนมากของ run-on-stream-of-programmer-consciousness ตลอดไปกับโมดูล ดังนั้นความเชื่อมั่นของฉัน (สำหรับสิ่งที่คุ้มค่า Liz ค่อนข้างจะไม่เห็นด้วยกับฉันเธอคิดว่าเป็นส่วนใหญ่การโต้ตอบที่ให้ FORTH เพิ่มประสิทธิภาพการผลิต)

— John R. Strohm

2

+1 เพื่อแนะนำหนังสือ "จิตวิทยาการเขียนโปรแกรมคอมพิวเตอร์" ที่ยอดเยี่ยมให้ฉัน :)

— ซามูเอล

30

ขนาดที่เหมาะสมจริงเหรอ?

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

เป็นการดีที่น้อยกว่า 25 บรรทัด
ได้รับการยอมรับน้อยกว่า 35 บรรทัด

ถ้ามันมากกว่านั้นมันเป็นสิ่งที่ฉันต้องกลับมาในภายหลังและทำใหม่

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

(เมื่อเร็ว ๆ นี้ทีมของฉันรันโปรแกรมบนโค้ดเบสของเรา: เราพบคลาสที่มี 197 วิธีและอีก 3 วิธีเท่านั้น แต่หนึ่งในนั้นคือ 600 ไลน์เกมน่ารัก: อะไรเลวร้ายกว่าของ 2 สิ่งเลวร้าย)

ตอนนี้สำหรับคำตอบที่เซนเพิ่มเติม ... โดยทั่วไปจะถือว่าเป็นวิธีปฏิบัติที่ดี (TM) ในการอ้างอิงชายผู้ยิ่งใหญ่หนึ่งหรือสองคนดังนั้นต่อไปนี้:

ทุกอย่างควรทำง่ายที่สุด แต่ไม่ง่ายกว่า - A. Einstein

ในที่สุดความสมบูรณ์แบบก็จะไม่เกิดขึ้นเมื่อไม่มีสิ่งใดที่จะเพิ่มอีกต่อไป แต่เมื่อไม่มีสิ่งใดที่จะเอาไปอีก - A. de Saint Exupéry

ภาคผนวกในรูปแบบความคิดเห็น

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

ความคิดเห็นพูดว่า"ทำไม" ,
รหัสบอกว่า"อย่างไร" .

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

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

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

@haylem ฉันเดานี้เป็นรุ่นโปรแกรมเมอร์ของศึกวันนรกแตก :-)

— Gaurav

ฉันเห็นด้วย แต่ฉันจะเพิ่มมันควรมีขนาดเท่ากับหน้าจอเดียว หากคุณมี 72 บรรทัดในหนึ่งหน้าจอฟังก์ชันจะต้องไม่เกิน 72 บรรทัด

— ชื่อที่แสดง

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

— haylem

1

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

— กำหนดค่า

1

เมื่อฟังก์ชั่นเป็นเช่นMap(x => x.Property1); Map(x => x.Property2); Map(x => x.Property3);มันชัดเจนว่ามันค่อนข้างเหมือนกันทั้งหมด (โปรดทราบว่านี่เป็นเพียงตัวอย่างฟังก์ชันประเภทนี้จะปรากฏขึ้นเป็นครั้งคราว)

— กำหนดค่า

12

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

หากต้องการใช้คำพูดของลุงบ๊อบ"ดึงข้อมูลจนกว่าคุณจะไม่สามารถแยกข้อมูลได้อีกแล้วแยกข้อมูลจนกว่าคุณจะลดลง"

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

2

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

— Kelmikra

10

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

— Huang F. Lei
แหล่งที่มา

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

— ซามูเอล

10

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

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

และวิธีการของคุณควรทำเพียงสิ่งเดียวเท่านั้นที่จะมีชื่อที่ดี ... ไม่ 'และ', 'หรือ' หรืออย่างอื่นที่ทำให้ชื่อวิธียาว 50 ตัวอักษร

— ซามูเอล

9

ตราบใดที่มันต้องทำสิ่งที่มันต้องทำ แต่ไม่นาน

— พอลนาธาน
แหล่งที่มา

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

— ชื่อที่แสดง

1

ที่จริงผมพลิกมันและพูดว่า "สั้นที่สุดเท่าที่จะต้องมี แต่ไม่สั้น" แต่คุณได้รับ +1 ของฉันสำหรับการอยู่ใกล้พอ :)

— เบนฮิวจ์

6

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

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

ในความเป็นจริงส่วนหนึ่งของการออกแบบวิธีการที่ดีคือการทำให้วิธีการทำงานร่วมกันอย่างเหนียวแน่น ความยาวของวิธีการไม่สำคัญ หากฟังก์ชั่นทำสิ่งหนึ่งที่กำหนดไว้อย่างดีและมี 1,000 บรรทัดมากกว่านั้นเป็นวิธีที่ดี หากฟังก์ชั่นทำสิ่งที่ 3 หรือ 4 และมีเพียง 15 บรรทัดก็เป็นวิธีที่ไม่ดี ...

— แชร์
แหล่งที่มา

ฉันชอบวิธีการสั้น ๆ

— Marcie

ฉันชอบสิ่งที่คุณพูดเพราะบอกว่าวิธีการไม่ควรมีมากกว่า 10 บรรทัดอยู่ในมุมมองของฉันยูโทเปีย ตกลงมันเป็นกฎที่ดีที่จะต้องจำไว้ทุกครั้งที่คุณเขียนวิธี แต่ไม่ควรเป็นกฎคณิตศาสตร์เช่น 1 + 1 = 2 หากคุณเคารพหลักการเช่น KISS, DRY, YAGNI ฯลฯ และวิธีการของคุณคือ ไม่เต็มความคิดเห็นอธิบายรายละเอียดบางอย่างเพราะมีความยาวเกินไปวิธีการสามารถมี 100 บรรทัดของรหัสและอาจจะทำความสะอาดและบำรุงรักษาโดยสิ้นเชิง อย่างไรก็ตามมันควรจะเป็นข้อยกเว้นมากกว่านิสัย ฉันคิดว่าการสลับเคสในวิธีการจากโรงงานเป็นตัวอย่างที่ดีของข้อยกเว้น

— ซามูเอล

5

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

สั้นพอที่จะพอดีกับจอภาพของฉันด้วยตัวอักษรที่เหมาะสม
หากต้องยาวเกิน # 1 ให้พิมพ์ให้สั้นพอที่จะพิมพ์ลงบนแผ่นกระดาษด้วยแบบอักษรที่เหมาะสม
หากจำเป็นต้องมีความยาวเกิน # 2 ให้สั้นพอที่จะพิมพ์ 2-up บนกระดาษหนึ่งแผ่น

ฉันไม่ค่อยเขียนฟังก์ชันนานกว่านั้น ส่วนใหญ่เป็นคำสั่งสวิตช์ C / C ++ ขนาดยักษ์

— บ๊อบเมอร์ฟี่ย์
แหล่งที่มา

สั้นพอที่จะใส่ลงในมอนิเตอร์ได้ดี แต่การระบุประเภทและขนาดตัวอักษร กระดาษไม่ควรเป็นกฎในมุมมองของฉันเพราะเราเป็นในปี 2013 และผู้ที่ยังคงพิมพ์รหัสบนกระดาษใครจะพิมพ์เพื่อดูว่ามันพอดีกับขนาดกระดาษหรือไม่ ด้วยเครื่องมือเช่น Visual Studio, Intellisense ไม่มีเหตุผลอีกต่อไปที่จะวิเคราะห์โค้ดด้วยกระดาษ

— ซามูเอล

5

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

โดยพื้นฐานแล้วฉันจะยึดติดกับ 'ความต่อเนื่องสูงการมีเพศสัมพันธ์ต่ำ' และไม่มีข้อ จำกัด เรื่องความยาว

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

5

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

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

ฉันได้เห็นSQL ที่ จัดเก็บโพรซีเดอร์ที่รันมากกว่า 1,000 บรรทัด จำนวนบรรทัดของโพรซีเดอร์ที่เก็บยังน้อยกว่า 50 หรือไม่? ฉันไม่รู้ แต่มันทำให้การอ่านรหัสเป็นไปได้ คุณไม่เพียง แต่ต้องเลื่อนขึ้นลงเรื่อย ๆ คุณต้องให้ชื่อโค้ดสองสามบรรทัดเช่น "this validation1", "การอัปเดตนี้ในฐานข้อมูล" ฯลฯ - งานที่โปรแกรมเมอร์ควรทำ

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

+1 สำหรับวรรคแรกเท่านั้น ทุกอย่างอื่นเกี่ยวข้องกับกรณีที่คุณกำลังทำงานอยู่

— ชื่อที่แสดง

5

จากความซับซ้อนของวัฏจักร (Wikipedia):

ความสลับซับซ้อนของส่วนของซอร์สโค้ดคือการนับจำนวนของเส้นทางที่เป็นอิสระเชิงเส้นผ่านซอร์สโค้ด

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

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

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

— John R. Strohm

4

โดยปกติแล้วฉันพยายามที่จะรักษาวิธีการ / ฟังก์ชั่นของฉันให้พอดีกับหน้าจอของจอภาพ 1680x1050 ถ้ามันไม่พอดีให้ใช้วิธีการ / ฟังก์ชั่นตัวช่วยเพื่อแยกงาน

ช่วยให้อ่านได้ทั้งบนหน้าจอและกระดาษ

— เจสัน
แหล่งที่มา

ฉันทำสิ่งเดียวกัน แต่คุ้มค่าที่จะระบุแบบอักษรและขนาดที่คุณใช้ สำหรับตัวฉันเองฉันชอบ "consolas" ที่มีขนาดเท่ากับ 14 ตามที่ Scott hanselman แนะนำ hanselman.com/blog/…เป็นครั้งแรกที่ทำงานกับตัวอักษรขนาดใหญ่ได้ยาก แต่เป็นวิธีปฏิบัติที่ดีที่สุดที่จะจดจำคุณไว้เสมอว่าวิธีการของคุณควรเล็กที่สุดเท่าที่จะทำได้

— ซามูเอล

4

สั้นพอที่จะปรับให้เหมาะสมอย่างถูกต้อง

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

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

ในภาษาระดับต่ำกว่าเช่น C หรือ C ++ การมีวิธีการสั้น ๆ (อาจจะเป็นโหลหรือมากกว่านั้น) ก็มีความสำคัญเช่นกันเพราะวิธีการที่คุณลดความต้องการในการจัดเก็บตัวแปรโลคัลใน RAM แทนการลงทะเบียน (Aka 'Register Spilling') โปรดทราบว่าในกรณีที่ไม่มีการจัดการค่าใช้จ่ายสัมพัทธ์ของการเรียกใช้ฟังก์ชันแต่ละครั้งอาจสูงมาก

และแม้แต่ในภาษาแบบไดนามิกเช่น Ruby หรือ Python การมีวิธีสั้น ๆ ก็ช่วยในการปรับแต่งคอมไพเลอร์ด้วยเช่นกัน ในภาษาไดนามิกคุณสมบัติยิ่ง 'ไดนามิก' ยิ่งยากที่จะปรับให้เหมาะสม ตัวอย่างเช่นวิธีการแบบยาวซึ่งใช้ X และสามารถคืนค่า Int, Float หรือ String จะทำงานช้ากว่าวิธีที่แยกกันสามวิธีซึ่งแต่ละวิธีจะส่งคืนชนิดเดียวเท่านั้น นี่เป็นเพราะหากคอมไพเลอร์รู้ว่าฟังก์ชั่นประเภทใดที่จะกลับมาก็สามารถเพิ่มประสิทธิภาพเว็บไซต์โทรฟังก์ชั่นเช่นกัน (เช่นไม่ใช่การตรวจสอบการแปลงประเภท)

— Chris Smith
แหล่งที่มา

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

— ซามูเอล

3

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

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

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

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

— Zoran Pavlovic

3

มันขึ้นอยู่กับว่ามีอะไรในรหัส

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

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

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

2

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

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

1

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

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

2) ฟังก์ชั่นที่ทำทั้งขั้นตอนเพื่อบรรลุเป้าหมายและขั้นตอนที่ขาดการแบ่งที่ดี คุณจบลงด้วยฟังก์ชั่นที่เรียกรายการฟังก์ชันอื่น ๆ ตามลำดับ

3) เหมือน # 2 แต่ในกรณีที่แต่ละขั้นตอนมีขนาดเล็กมากพวกมันจะถูก inline แทนที่จะเรียกแยกต่างหาก

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

1

บางทีความยาวของฟังก์ชั่นอาจไม่ได้ดีนัก เราพยายามใช้ความซับซ้อนของวงจรในวิธีการเช่นกันและหนึ่งในกฎการตรวจสอบแหล่งที่มาในอนาคตควบคุมว่าความซับซ้อนของวงจรในชั้นเรียนและวิธีการต้องต่ำกว่า X

สำหรับวิธีการ X ตั้งค่าเป็น 30 และนั่นค่อนข้างแน่น

— Peter Mortensen
แหล่งที่มา