การใช้รหัสที่ดีคืออะไรเมื่อทำฟังก์ชั่น / วิธีการสำหรับส่วนรหัสซ้ำขนาดเล็ก?

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

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

ตัวอย่างเช่นใน "Clean Code" Robert C. Martin ให้ตัวอย่างต่อไปนี้: คุณอยากเห็นอันไหน นี้:

// Check to see if the employee is eligible for full benefits
if ((employee.flags & HOURLY_FLAG) &&
    (employee.age > 65))

หรือสิ่งนี้

if (employee.isEligibleForFullBenefits())

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

ฉันไม่เคยเสียใจที่ต้องใส่อะไรในฟังก์ชั่นและถ้าคุณกังวลเกี่ยวกับการแสดง

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

หากมีการใช้งานมากกว่าหนึ่งแห่งและ

• อาจมีการเปลี่ยนแปลงหรือ
• มันยากที่จะทำถูก

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

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

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

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

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

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

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

ดูบทความวิกิพีเดียแนวคิดของรหัสการทำงานร่วมกัน

คุณต้องแยกความแตกต่างระหว่างฟังก์ชั่นในการเขียนโปรแกรมที่มีโครงสร้างและวิธีการของชั้นเรียน

ในตัวอย่างของคุณสิ่งที่คุณแสดงเป็นวิธีที่ไม่ควรเขียนโค้ดในบรรทัด

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

ความแตกต่างนี้มีความสำคัญเป็นพิเศษในโครงการขนาดใหญ่

ให้มากที่สุดเท่าที่จะทำได้พยายามแยกกฎธุรกิจ (นั่นคือวิธีการ) ออกจากอัลกอริธึมการคำนวณ