🧾 “ย้อนอดีตสู่อนาคต: ทำไมการจัดรูปแบบโค้ดควรเป็นเรื่องไม่จำเป็นตั้งแต่ยุค 80” ลองจินตนาการว่า...คุณกำลังเขียนโค้ดในปี 2025 แต่ยังต้องมานั่งเถียงกันเรื่องการเว้นวรรค, การใช้ tab หรือ space, หรือแม้แต่การตั้งค่า eslint ที่ทำให้ทีมปวดหัว ทั้งที่ปัญหาเหล่านี้ “ถูกแก้ไปแล้วตั้งแต่ยุค 80”! บทความนี้เล่าย้อนถึงประสบการณ์ของผู้เขียนกับครูสอนคอมพิวเตอร์ในโรงเรียนมัธยมที่เคยทำงานกับคอมไพเลอร์ภาษา Ada และ Rational R1000 ซึ่งเป็น workstation ที่ล้ำหน้ามากในยุคนั้น โดยใช้ระบบที่เรียกว่า DIANA (Descriptive Intermediate Attributed Notation for Ada) แทนการเก็บ source code แบบข้อความธรรมดา DIANA เป็น IR (Intermediate Representation) ที่สามารถแสดงผลในรูปแบบใดก็ได้ตามที่ผู้ใช้ต้องการ โดยไม่ต้องสนใจเรื่องการจัดรูปแบบโค้ดเลย เพราะสิ่งที่แสดงออกมาเป็นเพียง “ภาพพิมพ์สวยๆ” ของโครงสร้างโปรแกรมที่แท้จริง ซึ่งถูกจัดเก็บเป็นต้นไม้ข้อมูล (program tree) และแก้ไขได้โดยตรงผ่าน editor แบบ projectional editing Rational R1000 ยังมีฟีเจอร์ล้ำยุค เช่น incremental compilation, semantic analysis, version control และ debugging ที่ฝังอยู่ในระบบตั้งแต่ต้น ซึ่งช่วยให้การพัฒนาโปรแกรมขนาดใหญ่เป็นไปอย่างรวดเร็วและแม่นยำ แม้วันนี้เราจะมีเครื่องมือที่ดีขึ้น เช่น Claude ที่ช่วย refactor โค้ดได้ง่าย แต่ในเรื่องของการจัดรูปแบบ เรากลับถอยหลัง เพราะยังต้องเสียเวลาไปกับการตั้งค่าลินเตอร์และการตกแต่งโค้ด ทั้งที่เทคโนโลยีในอดีตเคยทำให้สิ่งเหล่านี้ “ไม่จำเป็น” มาแล้ว ✅ แนวคิดจากยุค 80 ที่ล้ำหน้ากว่าปัจจุบัน ➡️ DIANA เป็น IR ที่ใช้แทนการเก็บ source code แบบข้อความ ➡️ ผู้ใช้สามารถตั้งค่าการแสดงผลโค้ดได้ตามใจ โดยไม่กระทบต่อการทำงาน ➡️ Rational R1000 ใช้ DIANA เป็นแกนหลักในการพัฒนาโปรแกรม ➡️ ระบบสามารถแก้ไขโครงสร้างโปรแกรมโดยตรงผ่าน projectional editing ➡️ ไม่ต้องเถียงเรื่อง tab vs space หรือ eslint-config อีกต่อไป ✅ ฟีเจอร์ล้ำยุคของ Rational R1000 ➡️ มี incremental compilation สำหรับภาษา strongly typed ➡️ รองรับ semantic analysis และ version control ในตัว ➡️ ใช้ในการพัฒนาโปรแกรมระดับชาติ เช่น ISS และ F-22 ➡️ เป็นต้นกำเนิดของ UML โดย Grady Booch ➡️ IDE ที่ฝังอยู่ในระบบสามารถ debug และ refactor ได้ทันที ✅ บทเรียนสำหรับยุคปัจจุบัน ➡️ Claude และ AI agent ช่วยให้ refactor โค้ดได้ง่ายขึ้น ➡️ แต่การจัดรูปแบบโค้ดยังเป็นปัญหาที่ไม่ควรมีอีกต่อไป ➡️ ควรพิจารณาแนวทางใหม่ เช่น projectional editing หรือการใช้ IR ‼️ คำเตือนเกี่ยวกับการพึ่งพาเครื่องมือจัดรูปแบบ ⛔ การถกเถียงเรื่อง formatting อาจทำให้เสียเวลาโดยไม่จำเป็น ⛔ การบังคับใช้ eslint หรือ prettier อาจสร้างความขัดแย้งในทีม ⛔ การยึดติดกับรูปแบบโค้ดอาจบดบังเป้าหมายที่แท้จริงของการพัฒนา ⛔ การไม่เข้าใจโครงสร้างภายในของโค้ด อาจทำให้ refactor ผิดพลาด https://maxleiter.com/blog/formatting