โค้ดแบบเชิงเส้นอ่านง่ายกว่า

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

[GN⁺]

ความคิดเห็นบน Hacker News

• ความอ่านง่ายของโค้ดแบบเชิงเส้นและโค้ดแบบแยกเป็นโมดูลเป็นเรื่องของสไตล์ และต้องอาศัยวิจารณญาณกับความรู้สึกที่ดี
• การทำ abstraction มากเกินไปอาจทำให้เกิดการผูกติดกันของโค้ดเร็วเกินจำเป็น
• การแยกฟังก์ชันออกมาเพื่อทำ abstraction ของหน่วยงานสามารถช่วยจัดระเบียบอัลกอริทึมได้ แต่ควรใช้อย่างระมัดระวัง
• โค้ดตัวอย่างที่ให้มานั้นเรียบง่ายและขยายต่อได้ไม่ดี ควรคำนึงถึงการนำกลับมาใช้ซ้ำและความสามารถในการทำ unit test ด้วย
• การ refactor มากเกินไปอาจทำให้การบำรุงรักษายากขึ้น เพราะต้องย้ายส่วนอื่นของโค้ดตามไปด้วย
• โค้ดแบบเชิงเส้นอ่านง่ายเพราะลำดับการทำงานเป็นไปตามการรันจริง แต่ใน codebase ขนาดใหญ่จะขยายต่อได้ไม่ดี
• ฟังก์ชันที่กระชับแต่มี call stack ซ้อนลึกอาจกลายเป็นฝันร้ายใน codebase ขนาดใหญ่
• โค้ดเชิงเส้นที่ดีอ่านง่ายกว่า แต่ดูแลรักษาและทดสอบได้ยากกว่า
• การทำให้ฟังก์ชันมีขนาดเล็กที่สุดเท่าที่ทำได้และใกล้เคียงกับการมีจุดประสงค์เดียวถือเป็นแนวปฏิบัติที่ดี
• โครงสร้างของโค้ดควรถูกจัดตาม use case ทางธุรกิจเพื่อให้ย้ายไปมาหรือปรับเปลี่ยนได้ง่าย
• ทั้งโค้ดแบบเชิงเส้นและแบบแยกเป็นโมดูลต่างก็ถูกอ่านแบบเป็นลำดับ แต่ลำดับของฟังก์ชันก็อาจส่งผลต่อความอ่านง่ายได้
• โค้ดจริงมักซับซ้อนกว่านี้ และต้องมีภาพรวมระดับสูงเพื่อไม่ให้ผู้อ่านหลงอยู่ในรายละเอียดมากเกินไป