การถกเถียงเรื่องความยาวบรรทัดสูงสุดในการเขียนโปรแกรมที่มีมานานได้กลับมาเป็นประเด็นร้อนในชุมชนนักพัฒนาอีกครั้ง โดยเกิดจากการอภิปรายเกี่ยวกับการเลือกใช้ 88 ตัวอักษรเป็นขีดจำกัดเริ่มต้นของ Black Python formatter คำถามที่ดูเหมือนง่ายๆ นี้ได้แบ่งแยกโปรแกรมเมอร์มาหลายทศวรรษ โดยมีกลุ่มต่างๆ ที่สนับสนุนขีดจำกัดที่แตกต่างกันตั้งแต่ 80 ถึง 120 ตัวอักษรต่อบรรทัด
การอภิปรายนี้มีมิติที่ลึกกว่าเรื่องความชอบส่วนตัว ในขณะที่นักพัฒนาบางคนโต้แย้งเพื่อขีดจำกัด 80 ตัวอักษรแบบดั้งเดิมที่สืบทอดมาจากข้อจำกัดของเทอร์มินัล คนอื่นๆ กลับผลักดันให้ใช้บรรทัดที่ยาวขึ้นเพื่อรองรับจอแสดงผลแบบไวด์สกรีนสมัยใหม่และภาษาโปรแกรมมิ่งที่มีคำศัพท์ยาว
ข้อจำกัดความยาวบรรทัดยอดนิยมตามเครื่องมือ/มาตรฐาน:
- Black (Python): 88 ตัวอักษร (ค่าเริ่มต้น)
- Terminal แบบดั้งเดิม: 80 ตัวอักษร
- TeX/LaTeX: 66 ตัวอักษร (ปรับให้เหมาะสำหรับการพิมพ์)
- ความชอบของชุมชน: ช่วง 80-120 ตัวอักษร
- ค่าที่เหมาะสมที่สุดจากการวิจัย: 45-95 ตัวอักษรสำหรับร้อยแก้ว
- Fortran 77: 72 ตัวอักษร (เหตุผลทางประวัติศาสตร์)
วิทยาศาสตร์เบื้องหลังขีดจำกัดความยาวบรรทัด
การวิจัยเกี่ยวกับรูปแบบการอ่านของมนุษย์เผยให้เห็นว่าทำไมความยาวบรรทัดจึงสำคัญมาก เมื่อคนเราอ่านข้อความ ดวงตาของเราไม่ได้เคลื่อนที่อย่างราบรื่นข้ามบรรทัดเหมือนเคอร์เซอร์ แต่จะทำการเคลื่อนไหวแบบกระโดดอย่างรวดเร็วที่เรียกว่า saccades ระหว่างจุดคงที่ต่างๆ เพื่อให้ผู้อ่านสามารถกระโดดจากจุดสิ้นสุดของบรรทัดหนึ่งไปยังจุดเริ่มต้นของบรรทัดถัดไปได้อย่างแม่นยำ จุดเริ่มต้นของบรรทัดถัดไปจะต้องมองเห็นได้ในการมองเห็นรอบข้าง
ข้อจำกัดทางสรีรวิทยานี้อธิบายได้ว่าทำไมหนังสือพิมพ์จึงใช้คอลัมน์แคบๆ ประมาณ 30 ตัวอักษร และทำไมเว็บไซต์ส่วนใหญ่จึงจำกัดความกว้างของข้อความแม้ในมอนิเตอร์ขนาดใหญ่มาก หprinciples เดียวกันนี้ใช้กับการอ่านโค้ดได้ แม้ว่าการเขียนโปรแกรมจะมีความท้าทายเฉพาะตัวเรื่องการเยื้องและ syntax
Saccades: การเคลื่อนไหวของดวงตาอย่างรวดเร็วที่เกิดขึ้นเมื่อเปลี่ยนจุดโฟกัสจากจุดหนึ่งไปยังอีกจุดหนึ่งขณะอ่าน
การใช้หลาย Editor เทียบกับบรรทัดที่ยาวขึ้น
ข้อมูลเชิงลึกสำคัญจากชุมชนนักพัฒนาเน้นไปที่วิธีที่โปรแกรมเมอร์ใช้พื้นที่หน้าจอจริงๆ นักพัฒนาที่มีประสบการณ์หลายคนชอบขีดจำกัดบรรทัดที่สั้นกว่า ไม่ใช่เพราะพวกเขามีมอนิเตอร์ขนาดเล็ก แต่เพราะพวกเขาแบ่งหน้าจอเป็นแผงโค้ดหลายๆ แผง
ความแตกต่างระหว่างผม (คนที่ชอบ 80 คอลัมน์) กับศัตรูของผม (คนที่โง่กว่ามาก) คือพวกเขาใช้ buffer ใหญ่สวยงามอันเดียว ส่วนผมมี buffer 6-8 คอลัมน์เรียงข้างๆ กัน
แนวทางนี้ช่วยใช้ประโยชน์จากมอนิเตอร์ไวด์สกรีนได้สูงสุดโดยการแสดงไฟล์หลายๆ ไฟล์พร้อมกัน แทนที่จะยืดไฟล์เดียวข้ามความกว้างทั้งหมด นักพัฒนารายงานว่าวิธีนี้ช่วยรักษา context เมื่อทำงานกับโปรเจกต์ที่ซับซ้อน เนื่องจากไฟล์โค้ดที่เกี่ยวข้องสามารถมองเห็นได้โดยไม่ต้องสลับแท็บอยู่เรื่อยๆ
 |
|---|
| การออกแบบเรขาคณิตนี้แสดงถึงแนวทางที่มีโครงสร้างของนักพัฒนาในการจัดการ code buffer หลายตัวเพื่อให้เข้าใจบริบทได้ดีขึ้น |
ข้อพิจารณาเฉพาะภาษา
ความยาวบรรทัดที่เหมาะสมแตกต่างกันอย่างมากขึ้นอยู่กับภาษาโปรแกรมมิ่งที่ใช้ นักพัฒนา JavaScript และ Python มักพบว่า 80 ตัวอักษรเพียงพอ ในขณะที่ผู้ที่ทำงานกับ TypeScript หรือ Java ต่อสู้กับธรรมชาติที่ใช้คำยาวของภาษาเหล่านี้ type annotations ชื่อคลาสที่ยาว และ method signatures ที่ครอบคลุมสามารถทำให้ขีดจำกัดที่สั้นกว่ารู้สึกจำกัด
ภาษา object-oriented สมัยใหม่ทำให้ปัญหานี้รุนแรงขึ้นด้วยระดับการเยื้องที่ลึก method ของคลาส Python ทั่วไปอาจเริ่มต้นด้วยการเยื้อง 8-12 ช่องว่างก่อนที่จะมีโค้ดจริงๆ ซึ่งลดความกว้างของบรรทัดที่ใช้งานได้อย่างมีนัยสำคัญ
ปัจจัยที่ส่งผลต่อการเลือกความยาวบรรทัด:
- การตั้งค่าจอแสดงผล: จอภาพเดี่ยวขนาดใหญ่เทียบกับหลายหน้าต่างแยกส่วน
- ภาษาโปรแกรมมิ่ง: ภาษาที่ใช้คำศัพท์มาก ( Java , TypeScript ) เทียบกับภาษาที่กระชับ ( Python , JavaScript )
- ขั้นตอนการทำงานของทีม: ผู้ใช้แล็ปท็อปเทียบกับการตั้งค่าเดสก์ท็อป
- ระดับการเยื้อง: โค้ดเชิงวัตถุโดยทั่วไปใช้ 8-12 ช่องว่างก่อนเนื้อหา
- การรวมเครื่องมือ: การดู diff การแก้ไขข้อขัดแย้งในการผสาน อินเทอร์เฟซการตรวจสอบโค้ด
- การกำหนดค่า IDE: แผงด้านข้างและหน้าต่างเครื่องมือลดความกว้างที่ใช้ได้
เครื่องมือและพลวัตของทีม
การเพิ่มขึ้นของ code formatters ที่มีความเห็นแน่นอนเช่น Black, gofmt และ Prettier ได้เปลี่ยนการสนทนาจากความชอบส่วนตัวไปสู่การมาตรฐานของทีม เครื่องมือเหล่านี้ขจัด bikeshedding โดยการตัดสินใจเรื่องการจัดรูปแบบโดยอัตโนมัติ แม้ว่าแต่ละตัวจะจัดการความยาวบรรทัดแตกต่างกัน
formatter บางตัวหลีกเลี่ยงการตัดบรรทัดทั้งหมด ทำให้เกิดผลลัพธ์ที่ไม่สอดคล้องกัน ตัวอื่นๆ ใช้อัลกอริทึมที่ซับซ้อนเพื่อกำหนดจุดตัดที่เหมาะสม แต่อาจไม่สนับสนุนขีดจำกัดตัวอักษรแบบแข็งตัว สิ่งนี้สร้างความตึงเครียดระหว่างการจัดรูปแบบอัตโนมัติและการบังคับใช้ความยาวบรรทัดด้วยตนเอง
จุดกึ่งกลางที่ปฏิบัติได้
แม้จะมีการถกเถียงอย่างดุเดือด นักพัฒนาส่วนใหญ่ดูเหมือนจะมาบรรจบกันที่ขีดจำกัดระหว่าง 88 ถึง 120 ตัวอักษร ช่วงนี้ให้พื้นที่เพียงพอสำหรับโครงสร้างการเขียนโปรแกรมสมัยใหม่ในขณะที่รักษาความสามารถในการอ่านและความเข้ากันได้กับ workflow การแก้ไขแบบเคียงข้างกัน
การเลือกมักขึ้นอยู่กับองค์ประกอบของทีมและเครื่องมือ ทีมที่ใช้แล็ปท็อปหรือมอนิเตอร์ขนาดเล็กมักโน้มไปสู่ขีดจำกัดที่สั้นกว่า ในขณะที่ทีมที่มีจอแสดงผลขนาดใหญ่และ IDE ที่ไม่รกรุงรังสามารถรองรับบรรทัดที่ยาวขึ้นได้ ข้อพิจารณาเรื่อง version control ก็มีบทบาทเช่นกัน เนื่องจากบรรทัดที่สั้นกว่าโดยทั่วไปจะสร้าง diff ที่สะอาดกว่าและแก้ไข merge conflict ได้ง่ายกว่า
แทนที่จะแสวงหาคำตอบสากล ทีมพัฒนาที่ประสบความสำเร็จมุ่งเน้นไปที่ความสอดคล้องภายในโปรเจกต์ของพวกเขาและเลือกขีดจำกัดที่สนับสนุน workflow และการตั้งค่าการแสดงผลเฉพาะของพวกเขา
อ้างอิง: The Best Line Length
 |
|---|
| ลูกศรที่มีสไตล์เป็นสัญลักษณ์ของการเคลื่อนไหวไปข้างหน้าในการบรรลุข้อตกลงร่วมกันเกี่ยวกับขีดจำกัดความยาวของบรรทัดในการเขียนโปรแกรม |