โลกการเขียนโปรแกรมปะทุด้วยการอภิปรายอย่างเร่าร้อนหลังจากบทความล่าสุดประกาศการสิ้นสุดของสงครามในตำนานระหว่าง tabs กับ spaces ในการจัดย่อหน้า โดยอ้างว่า spaces ได้รับชัยชนะ อย่างไรก็ตาม การตอบสนองของชุมชนนักพัฒนาชี้ให้เห็นว่าการต่อสู้ครั้งนี้ยังไกลจากการจบสิ้น
 |
|---|
| การแสดงภาพการถกเถียงที่ยืนยาว: Tabs เทียบกับ Spaces |
ข้อโต้แย้งเรื่องการเข้าถึงและความยืดหยุ่นกลับมาอีกครั้ง
ผู้สนับสนุน tab รีบรวมตัวกันรอบข้อโต้แย้งหลักของพวกเขา คือการเข้าถึงได้และการเลือกของผู้ใช้ นักพัฒนาหลายคนเน้นย้ำว่า tabs ช่วยให้โปรแกรมเมอร์แต่ละคนสามารถตั้งค่าความกว้างที่ต้องการในการแสดงผล ซึ่งสำคัญเป็นพิเศษสำหรับผู้ที่มีความบกพร่องทางสายตาหรือการตั้งค่าหน้าจอที่แตกต่างกัน ความยืดหยุ่นนี้หมายความว่านักพัฒนาคนหนึ่งสามารถดูโค้ดด้วย tabs ที่กว้าง 2 ช่องว่าง ในขณะที่อีกคนใช้ 4 ช่องว่าง ทั้งหมดจากไฟล์ต้นฉบับเดียวกัน
ข้อโต้แย้งตรงข้ามจากผู้สนับสนุน spaces มุ่งเน้นไปที่ความสม่ำเสมอและปัญหาการจัดตำแหน่ง เมื่อโค้ดต้องการตัดบรรทัดที่ความยาวเฉพาะหรือเมื่อนักพัฒนาสร้างการจัดตำแหน่งแบบภาพในโค้ดของพวกเขา tabs สามารถสร้างปัญหาได้เพราะความกว้างของ tab ที่แตกต่างกันทำให้โค้ดปรากฏแตกต่างกันต่อผู้ดูแต่ละคน
ความชอบในการใช้ Tab Width ที่พบบ่อย
- 2 spaces: เป็นที่ชื่นชอบสำหรับการพัฒนาเว็บ ( JavaScript , CSS , HTML )
- 3 spaces: มีผู้สนับสนุนบางกลุ่มเพื่อความสามารถในการอ่านที่เหมาะสม
- 4 spaces: เป็นค่าเริ่มต้นที่พบมากที่สุดในทุกภาษา
- 8 spaces: ค่าเริ่มต้นแบบดั้งเดิมของ Unix/terminal ใช้ในโปรเจกต์ C บางโปรเจกต์
อักขระ Tab ช่วยให้ผู้ใช้สามารถกำหนดค่าความกว้างที่แสดงผลได้ ในขณะที่ spaces บังคับใช้ระยะห่างแบบคงที่
แนวทางผสมผสานได้รับความสนใจ
ส่วนสำคัญของชุมชนได้อภิปรายเกี่ยวกับกลยุทธ์ tabs สำหรับการจัดย่อหน้า spaces สำหรับการจัดตำแหน่ง แนวทางแบบผสมผสานนี้พยายามได้ประโยชน์ที่ดีที่สุดจากทั้งสองโลกโดยใช้ tabs เฉพาะสำหรับโครงสร้างโค้ดพื้นฐานและ spaces สำหรับการจัดแนวองค์ประกอบภายในระดับตรรกะเดียวกัน อย่างไรก็ตาม นักพัฒนาหลายคนสังเกตว่าแนวทางนี้ยากที่จะบังคับใช้ในทางปฏิบัติ เนื่องจากลักษณะที่มองไม่เห็นของตัวอักษรเหล่านี้ทำให้สมาชิกในทีมผสมผสานได้อย่างไม่ถูกต้องได้ง่าย
เครื่องมือสมัยใหม่เปลี่ยนเกม
การอภิปรายเผยให้เห็นว่าเครื่องมือพัฒนาสมัยใหม่ได้เปลี่ยนภูมิทัศน์ของการถกเถียงไปอย่างไร ตัวจัดรูปแบบอัตโนมัติเช่น gofmt ของ Go ตัวจัดรูปแบบของ Rust และ Prettier สำหรับ JavaScript ตอนนี้จัดการการจัดย่อหน้าโดยอัตโนมัติ ลบการตัดสินใจด้วยตนเองส่วนใหญ่ที่เคยเป็นเชื้อเพลิงให้กับข้อโต้แย้งเหล่านี้ นักพัฒนาบางคนโต้แย้งว่าสิ่งนี้ทำให้การถกเถียงทั้งหมดมีความเกี่ยวข้องน้อยลง เนื่องจากเครื่องมือบังคับใช้ความสม่ำเสมอโดยไม่คำนึงถึงความชอบส่วนตัว
สิ่งสำคัญที่สุดคือความสม่ำเสมอ ผมกลายเป็นแฟนตัวยงของการมอบหมายการถกเถียง tabs vs spaces ให้กับตัวจัดรูปแบบอัตโนมัติ
Auto-formatters สมัยใหม่จำแนกตามภาษา
| ภาษา | Formatter | รูปแบบเริ่มต้น |
|---|---|---|
| Go | gofmt |
Tabs (บังคับใช้) |
| Rust | rustfmt |
4 spaces |
| JavaScript/TypeScript | Prettier | 2 spaces |
| Dart | dartfmt |
2 spaces |
| Gleam | Built-in formatter | 2 spaces |
Auto-formatters ช่วยลดการตัดสินใจในการจัดรูปแบบด้วยตนเองและบังคับใช้ความสม่ำเสมอ
ตัวเลขไม่ได้บอกเล่าเรื่องราวทั้งหมด
ในขณะที่บทความต้นฉบับอ้างว่าประมาณ 90% ของภาษาโปรแกรมมิ่งใช้ spaces เป็นค่าเริ่มต้น สมาชิกชุมชนตั้งคำถามว่าตัวชี้วัดนี้สะท้อนการใช้งานจริงหรือไม่ บางคนแนะนำว่าการวัดจากจำนวนบรรทัดของโค้ดที่เขียนหรือไฟล์ที่ประมวลผลอาจแสดงให้เห็นว่า tabs อยู่ในตำแหน่งที่แข็งแกร่งกว่า โดยเฉพาะอย่างยิ่งเมื่อพิจารณาถึงความแพร่หลายในภาษาหลักเช่น Go และในฐานโค้ดเก่า
การถกเถียงยังเผยให้เห็นความแปรผันที่น่าสนใจในความกว้างการจัดย่อหน้าที่ต้องการ โดยนักพัฒนาบางคนสนับสนุนการจัดย่อหน้า 3 ช่องว่างว่าเหมาะสมที่สุดสำหรับการอ่าน แม้ว่าจะไม่ใช่เลขยกกำลังของสอง
ภาษาโปรแกรมจำแนกตามการเยื้องแบบเริ่มต้น
| ประเภทการเยื้อง | ภาษาโปรแกรม |
|---|---|
| ช่องว่าง (2) | Ruby, JavaScript, TypeScript, CSS, HTML, JSON |
| ช่องว่าง (4) | Python, Java, C, PHP, Kotlin, Swift |
| แท็บ | Go, Assembly, Hare, Odin |
| ผสม/แปรผัน | C, C++ (ขึ้นอยู่กับโปรเจกต์) |
ประมาณ 90% ของภาษาโปรแกรมหลักใช้ช่องว่างเป็นค่าเริ่มต้นตามคู่มือสไตล์อย่างเป็นทางการ
บทสรุป
แทนที่จะยุติเรื่องนี้ การประกาศชัยชนะของ spaces ในบทความกลับจุดชนวนให้การถกเถียงที่ยาวนานที่สุดอย่างหนึ่งในการเขียนโปรแกรมกลับมาคึกคักอีกครั้ง การตอบสนองของชุมชนแสดงให้เห็นว่าทั้งสองฝ่ายยังคงมีข้อโต้แย้งทางเทคนิคและปรัชญาที่แข็งแกร่ง แม้ว่าเครื่องมือสมัยใหม่อาจลดผลกระทบในทางปฏิบัติของการเลือกนี้ แต่ความตึงเครียดพื้นฐานระหว่างการมาตรฐานและการปรับแต่งส่วนบุคคลในสภาพแวดล้อมการพัฒนารับประกันว่าการอภิปรายนี้น่าจะดำเนินต่อไปอีกหลายปี
ความเร่าร้อนในการตอบสนองเหล่านี้แสดงให้เห็นว่าสำหรับนักพัฒนาหลายคน การเลือกระหว่าง tabs และ spaces แสดงถึงสิ่งที่ลึกซึ้งกว่าความชอบในการจัดรูปแบบเพียงอย่างเดียว มันสะท้อนปรัชญาที่แตกต่างกันเกี่ยวกับวิธีที่โค้ดควรถูกเขียน แบ่งปัน และดูแลรักษาในสภาพแวดล้อมการทำงานร่วมกัน
อ้างอิง: Tabs vs. Spaces: The War Is Over