มีจำนวนบรรทัดที่ดีที่สุดของรหัสต่อหน้าที่หรือไม่? [ปิด]

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

สิ่งนี้ทำให้ฉันสงสัย: มีจำนวน LOCs ที่เหมาะสมที่สุดต่อการทำงานหรือไม่? ถ้าใช่มันคืออะไรและมีความแตกต่างระหว่างภาษาหรือไม่

แทนที่จะเป็นจำนวนบรรทัดเกณฑ์ที่ฉันจะใช้ก็คือแต่ละฟังก์ชั่นควรทำเพียงสิ่งเดียวและทำได้ดี

กฎนิ้วหัวแม่มือเก่าคือฟังก์ชั่นควรจะมองเห็นได้ทั้งหมดบนหน้าจอโดยไม่จำเป็นต้องเลื่อน

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

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

ไม่มีเลย

หน้าจอเริ่มใหญ่ขึ้นขนาดตัวอักษรเล็กลง กฎของหัวแม่มือไม่ทำงานได้ดีเมื่อผู้ที่มีนิ้วหัวแม่มือขนาดแตกต่างกัน

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

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

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

ดังนั้นใน Smalltalk สภาพแวดล้อม "สนับสนุน" ให้คุณเขียนวิธีการสั้น ๆ โดยมีความยาวไม่เกิน 6 บรรทัด (นั่นมักจะมาก; Smalltalk เป็นภาษาที่ค่อนข้างสั้น)

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

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

"ไม่เช่นนั้นเราจะมีฟังก์ชั่นเป็นตันซึ่งทั้งหมดมีเพียงบรรทัดเดียวหรือสองโค้ด"

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

คำตอบคือแน่นอน42

สำคัญที่ควรทราบ: ไม่มี funcion อาจเคยละเมิดSRPหรือคุณต้องเผชิญกับการสืบสวน Spanisch

บางคำแนะนำวิธีการลดจำนวนบรรทัด:

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

นี่คือเคล็ดลับบางอย่าง:

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

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

• หากคุณกำลังวางรหัสจากฟังก์ชันอื่นทั้งคู่จะยาวเกินไป (แยกรหัสนั้นเป็นฟังก์ชันแยกต่างหาก)

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

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

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