ความยาวในอุดมคติของวิธีการสำหรับคุณคืออะไร? [ปิด]

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

ในรหัสที่สะอาด: คู่มือของงานฝีมือซอฟต์แวร์เปรียว Robert Martin กล่าวว่า:

กฎข้อแรกของฟังก์ชั่นคือมันควรมีขนาดเล็ก กฎข้อที่สองของฟังก์ชั่นคือควรมีขนาดเล็กกว่านั้น ฟังก์ชั่นไม่ควรยาว 100 บรรทัด ฟังก์ชั่นแทบจะไม่เคยมีความยาว 20 บรรทัด

และเขายกตัวอย่างจากโค้ด Java ที่เขาเห็นจาก Kent Beck:

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

สิ่งนี้ฟังดูยอดเยี่ยม แต่ในทางกลับกันในCode Complete Steve McConnell พูดอะไรบางอย่างที่แตกต่างกันมาก:

รูทีนควรได้รับอนุญาตให้เติบโตอย่างเป็นธรรมชาติถึง 100-200 บรรทัดหลักฐานหลายทศวรรษบอกว่ากิจวัตรที่มีความยาวดังกล่าวไม่มีข้อผิดพลาดเกิดขึ้นได้ง่าย

และเขาให้การอ้างอิงถึงการศึกษาที่ระบุว่ากิจวัตร 65 บรรทัดหรือยาวกว่านั้นถูกกว่าเพื่อพัฒนา

ดังนั้นในขณะที่มีการแยกความคิดเห็นเกี่ยวกับเรื่องนี้มีวิธีปฏิบัติที่ดีที่สุดสำหรับคุณหรือไม่?

ฟังก์ชั่นควรสั้นปกติระหว่าง 5-15 บรรทัดคือ "rule of thumb" ส่วนตัวของฉันเมื่อเขียนโค้ดใน Java หรือ C # นี่คือขนาดที่ดีด้วยเหตุผลหลายประการ:

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

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

• ฟังก์ชั่นการเข้าถึงแบบบรรทัดเดียวที่ดำเนินการส่งแบบเป็นที่ยอมรับอย่างชัดเจนในบางสถานการณ์
• มีฟังก์ชั่นสั้น ๆ แต่มีประโยชน์ (เช่นสลับตามที่ผู้ใช้ไม่รู้จัก) ซึ่งต้องการน้อยกว่า 5 บรรทัดอย่างชัดเจน ไม่ใช่เรื่องใหญ่ฟังก์ชั่น 3 บรรทัดบางรายการไม่ส่งผลเสียใด ๆ ต่อฐานรหัสของคุณ
• ฟังก์ชั่น 100 บรรทัดที่เป็นคำสั่งสวิตช์ขนาดใหญ่อาจยอมรับได้หากชัดเจนว่ากำลังทำอะไรอยู่ รหัสนี้เป็นแนวคิดที่ง่ายมากแม้ว่าจะต้องมีบรรทัดจำนวนมากเพื่ออธิบายกรณีที่แตกต่างกัน บางครั้งมีข้อเสนอแนะว่าสิ่งนี้ควรได้รับการแบ่งเป็นชั้นเรียนที่แยกจากกันและดำเนินการโดยใช้การสืบทอด / ความหลากหลาย แต่ IMHO สิ่งนี้ทำให้ OOP มากเกินไป - ฉันควรมีคำสั่งสวิตช์ 40 ทางใหญ่กว่า 40 ชั้นเรียนใหม่ เป็นคำสั่งเปลี่ยน 40 ทางเพื่อสร้าง
• ฟังก์ชั่นที่ซับซ้อนอาจมีตัวแปรสถานะจำนวนมากที่จะได้รับยุ่งมากถ้าผ่านระหว่างฟังก์ชั่นที่แตกต่างกันเป็นพารามิเตอร์ ในกรณีนี้คุณสามารถโต้แย้งได้ว่ารหัสนั้นง่ายกว่าและง่ายกว่าถ้าคุณเก็บทุกอย่างไว้ในฟังก์ชั่นใหญ่ ๆ เดียว (แม้ว่า Mark จะชี้ให้เห็นอย่างถูกต้องว่านี่อาจเป็นตัวเลือกสำหรับการเปลี่ยนเป็นคลาส และรัฐ)
• บางครั้งฟังก์ชันที่เล็กกว่าหรือใหญ่กว่าย่อมมีข้อได้เปรียบด้านประสิทธิภาพ (อาจเป็นเพราะเหตุผลแบบอินไลน์หรือ JIT ตามที่แฟรงก์กล่าวไว้) มันขึ้นอยู่กับการนำไปใช้อย่างมาก แต่ก็สามารถสร้างความแตกต่างได้ - ให้แน่ใจว่าคุณเป็นมาตรฐาน!

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

ในขณะที่ฉันเห็นด้วยกับความคิดเห็นของผู้อื่นเมื่อพวกเขาบอกว่าไม่มีกฎเกณฑ์ที่เข้มงวดเกี่ยวกับหมายเลข LOC ที่ถูกต้องฉันเดิมพันถ้าเรามองย้อนกลับไปที่โครงการที่เราเคยดูในอดีตและระบุทุกฟังก์ชั่นด้านบนสมมุติว่ารหัส 150 บรรทัด ฉันเดาว่าเราจะได้รับฉันทามติว่า 9 ใน 10 ของฟังก์ชั่นเหล่านั้นแตก SRP (และ OCP ที่น่าจะเป็นไปได้เช่นกัน) มีตัวแปรท้องถิ่นมากเกินไปการควบคุมกระแสมากเกินไปและมักอ่านและบำรุงรักษายาก

ดังนั้นในขณะที่ LOC อาจไม่ได้เป็นตัวบ่งชี้โดยตรงของรหัสที่ไม่ดี แต่ก็เป็นตัวบ่งชี้ทางอ้อมที่ดีที่แน่นอนว่าฟังก์ชั่นบางอย่างสามารถเขียนได้ดีขึ้น

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

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

กฎทั่วไปของวิธีการที่ใหญ่ที่สุดในบางครั้งก็ไม่ดีนัก ฉันชอบกฎของโรเบิร์ตซีมาร์ติน (ลุงบ๊อบ): "วิธีการควรมีขนาดเล็กกว่าเล็ก" ฉันพยายามที่จะใช้กฎนี้ตลอดเวลา ฉันกำลังพยายามทำให้วิธีการของฉันง่ายและเล็กโดยชี้แจงว่าวิธีการของฉันทำสิ่งเดียวและไม่มีอะไรเพิ่มเติม

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

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

หากคุณเพียงแค่ทำตาม SRP วิธีการส่วนใหญ่ของคุณจะเล็กและมีเจตนาชัดเจน

ไม่ถูกต้องที่จะพูดว่า "วิธีนี้คือ> 20 บรรทัดดังนั้นจึงผิด" มันอาจจะเป็นข้อบ่งชี้ว่าสิ่งที่อาจจะผิดปกติกับวิธีการนี้ไม่มาก

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

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

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

ฉันคิดว่าปัญหาหนึ่งคือความยาวของฟังก์ชันไม่ได้พูดถึงความซับซ้อนของมัน LOC (Lines of Code) เป็นเครื่องมือที่ไม่ดีในการวัดทุกอย่าง

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

ตัวอย่างเช่นตัวจัดการข้อมูลที่เข้ามาสามารถมีคำสั่งสวิตช์ขนาดใหญ่แล้วรหัสง่าย ๆ ต่อกรณี ฉันมีรหัสดังกล่าว - การจัดการข้อมูลขาเข้าจากฟีด 70 (!) ตัวจัดการการเข้ารหัสตัวเลข ตอนนี้หนึ่งจะพูดว่า "ใช้ค่าคงที่" - ใช่ยกเว้น API ไม่ได้ให้พวกเขาและฉันชอบที่จะอยู่ใกล้กับ "แหล่งที่มา" ที่นี่ วิธี? แน่นอนว่าน่าเศร้าที่พวกเขาทั้งหมดจัดการกับข้อมูลจากโครงสร้างขนาดใหญ่ 2 ตัวเดียวกัน ไม่มีประโยชน์ในการแยกออกยกเว้นอาจมีวิธีเพิ่มเติม (อ่านง่าย) รหัสไม่ได้มีความซับซ้อนมาก - สวิตช์เดียวขึ้นอยู่กับเขตข้อมูล จากนั้นทุกกรณีจะมีบล็อกที่แยกวิเคราะห์องค์ประกอบของข้อมูลและเผยแพร่ ไม่มีฝันร้ายบำรุงรักษา มีการทำซ้ำ "ถ้าเงื่อนไขที่กำหนดว่าเขตข้อมูลมีข้อมูล (pField = pFields [x] ถ้า pField-> IsSet () {blabla}) - เหมือนกันมากสำหรับทุกเขต ..

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

ดังนั้นขออภัย LOC ไม่ใช่การเริ่มต้นที่ดี หากมีสิ่งใดควรใช้คะแนนความซับซ้อน / การตัดสินใจ

ฉันแค่จะโยนใบเสนอราคาอีก

โปรแกรมจะต้องถูกเขียนขึ้นเพื่อให้ผู้คนอ่านและมีเพียงเครื่องที่จะทำงานเท่านั้น

- แฮโรลด์ Abelson

มันไม่น่าเป็นไปได้มากที่ฟังก์ชั่นที่เติบโตถึง 100-200 ปฏิบัติตามกฎนี้

ฉันอยู่ในแร็กเกตบ้าๆอย่างนี้ไม่ทางใดก็ทางหนึ่งตั้งแต่ปี 1970

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

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

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

อีกอย่างคืองานตอร์ปิโดโฟตอนจาก Matuszek-Reynolds-McGehearty-Cohen STARTRK game ที่เขียนใน CDC 6600 FORTRAN IV มันต้องแยกบรรทัดคำสั่งจากนั้นจำลองการบินของแต่ละตอร์ปิโดด้วยการก่อกวนตรวจสอบการทำงานร่วมกันระหว่างตอร์ปิโดและสิ่งต่าง ๆ ที่มันสามารถโจมตีได้ โนวาจากตอร์ปิโดดาวที่อยู่ถัดจากดาวดวงอื่น

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

ไม่มีกฎที่สมบูรณ์เกี่ยวกับความยาวของวิธีการ แต่กฎต่อไปนี้มีประโยชน์:

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

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

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

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

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

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

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

ดังนั้นมันขึ้นอยู่กับสภาพแวดล้อมการเขียนโปรแกรมตามปกติของการทำงานเป็นทีมของคุณ (ความละเอียดหน้าจอ, แก้ไข, ขนาดตัวอักษร, ฯลฯ ... ) ในยุค 80 มันคือ 25 บรรทัดและ 80 คอลัมน์ ตอนนี้ในเครื่องมือแก้ไขของฉันฉันแสดงเกือบ 50 บรรทัด จำนวนคอลัมน์ที่ฉันแสดงไม่เปลี่ยนแปลงเนื่องจากฉันแบ่งหน้าจอเป็นสองไฟล์เพื่อแสดงสองไฟล์ในบางครั้ง

โดยสังเขปมันขึ้นอยู่กับการตั้งค่าของเพื่อนร่วมงานของคุณ

ฉันคิดว่าคำตอบของ TomTomมาใกล้กับความรู้สึกของฉัน

ฉันพบว่าตัวเองมีความซับซ้อนมากขึ้นเรื่อย ๆ มากกว่าเป็นเส้น

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

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

โปรดทราบว่าฉันไม่ได้นับตรรกะยามกับขีด จำกัด นี้

ใน OOP ทุกสิ่งวัตถุและมีคุณสมบัติเหล่านี้:

1. ความแตกต่าง
2. สิ่งที่เป็นนามธรรม
3. มรดก

เมื่อคุณปฏิบัติตามกฎเหล่านี้แล้ววิธีการของคุณมักจะเล็ก แต่ไม่มีกฎใด ๆ สำหรับกฎเล็ก ๆ หรือเล็กมาก (เช่น 2-3 บรรทัด) กฎ ประโยชน์ของวิธีการขนาดเล็ก (หน่วยขนาดเล็กเช่นวิธีการหรือฟังก์ชั่น) คือ:

1. อ่านได้ดีขึ้น
2. รักษาดีกว่า
3. แก้ไขข้อผิดพลาดที่ดีกว่า
4. การเปลี่ยนแปลงที่ดีขึ้น