การจัดรูปแบบโค้ดไม่ควรเป็นสิ่งจำเป็น

 (maxleiter.com)
1 คะแนน โดย GN⁺ 2025-09-09 | 4 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในอดีต สภาพแวดล้อมการพัฒนา Ada เคยมีประสบการณ์แก้ปัญหาการจัดรูปแบบโค้ดไว้แล้ว
  • นักพัฒนาไม่ได้ทำงานกับโค้ดในรูป ข้อความซอร์สโค้ด โดยตรง แต่ใช้รูปแบบตัวแทนกลาง DIANA (IR) และแต่ละคนสามารถดูโค้ดด้วยการตั้งค่า pretty-printing ตามที่ตนต้องการ
  • แม้ในปัจจุบันก็ยังมี ความไม่มีประสิทธิภาพและข้อถกเถียง ที่เกิดซ้ำจาก linter หรือกฎการฟอร์แมต
  • ในเวลานั้น เวิร์กสเตชัน Rational R1000 มอบสภาพแวดล้อมและความสามารถด้านการพัฒนาที่ล้ำสมัย
  • บทความเสนอไอเดียให้ย้อนดูแนวทางเมื่อหนึ่งรุ่นก่อนในปัญหาการจัดรูปแบบโค้ด เพื่อ เปลี่ยนแปลงแนวปฏิบัติการพัฒนาในปัจจุบัน

ข้อถกเถียงเรื่องการจัดรูปแบบโค้ด – คำตอบจากทศวรรษ 1980

  • ผู้เขียนกล่าวถึงประสบการณ์กับ Mr. Paige ครูวิทยาการคอมพิวเตอร์ที่เคยมีส่วนร่วมกับงานคอมไพเลอร์ Ada ตั้งแต่สมัยผู้เขียนเรียนมัธยม
  • ในปี 2016 เมื่อผู้เขียนบ่นถึงความไม่สะดวกในการตั้งค่าเครื่องมือ linter และถามว่า “ทำไมเรายังต้องเจอปัญหาแบบนี้อยู่” ก็ได้รับฟังว่าปัญหานี้เคยถูกแก้ไปแล้วตั้งแต่กว่า 40 ปีก่อน

การมาของ Ada และ DIANA

  • แทนที่จะเก็บ ซอร์สโค้ดแบบข้อความ นักพัฒนา Ada ใช้รูปแบบตัวแทนกลางชื่อ DIANA (Descriptive Intermediate Attributed Notation for Ada)
  • นักพัฒนาแต่ละคนสามารถเปิดดูซอร์สด้วย การตั้งค่า pretty-printing ของตัวเองได้ตามต้องการ
  • ไม่มีข้อถกเถียงเรื่องการฟอร์แมตหรือปัญหา linter และในเอดิเตอร์ยังสามารถแก้ไขต้นไม้ของโปรแกรมได้โดยตรง (คล้ายกับ projectional editing ในปัจจุบัน)

Rational R1000 – สภาพแวดล้อมการพัฒนาผู้บุกเบิก

  • เวิร์กสเตชัน Rational R1000 มีฟีเจอร์ขั้นสูงในตัวมากมาย เช่น incremental compilation, static analysis, version control, และ debugging
  • ระบบนี้ถูกใช้ในโครงการซอฟต์แวร์สำคัญของภาครัฐ เช่น DoD รวมถึงสถานีอวกาศนานาชาติ (ISS) และเครื่องบินขับไล่ F-22 อีกทั้งยังมีส่วนต่อการกำเนิดของ UML
  • ตามคำกล่าวของ Grady Booch นั้น R1000 เป็นเครื่องที่ทำงานบน DIANA โดยไม่เก็บซอร์สโค้ด และใช้เพียงการ pretty-print ต้นไม้ DIANA เท่านั้น

ข้อดีของการพัฒนาบนฐาน DIANA

  • ไม่จำเป็นต้องมีข้อถกเถียงเรื่องการฟอร์แมต การตั้งค่า linter หรือการทำให้สภาพแวดล้อมเอดิเตอร์เป็นแบบเดียวกัน
  • การเร่งความเร็วด้วยฮาร์ดแวร์ทำให้เกิดประสบการณ์การพัฒนาที่ล้ำหน้า เช่น incremental compilation, การรีแฟกเตอร์ที่ทำได้ง่าย, และการรวมงานที่รวดเร็ว
  • สิ่งนี้ส่งผลสำคัญต่อประสิทธิภาพการพัฒนาและการทำงานกับระบบขนาดใหญ่

สิ่งที่สะท้อนมาถึงปัจจุบัน

  • แม้การคอมไพล์แบบเร่งด้วยฮาร์ดแวร์จะมีความสำคัญลดลง แต่การแก้ปัญหาเรื่องการฟอร์แมตยังคงไม่สมบูรณ์
  • แม้แนวทางกระแสหลักจะยังไม่ใช่ projectional editing หรือสภาพแวดล้อมแบบ live แต่ก็น่าถึงเวลาพิจารณานำ แนวปฏิบัติการพัฒนาที่มีประสิทธิภาพมากกว่าและมีข้อถกเถียงน้อยกว่า แบบที่เคยมีในอดีตกลับมาปรับใช้

เอกสารอ้างอิง

  • ผู้เขียนอ้างอิงเอกสารและรายงานทางเทคนิคหลากหลายฉบับที่เกี่ยวข้องกับ R1000 ระหว่างการศึกษาหัวข้อนี้

บทความที่เกี่ยวข้อง

4 ความคิดเห็น

 
ndrgrd 2025-09-10

เท่าที่ทราบ ตอนนี้โค้ดที่แชร์กันก็มีฟีเจอร์ที่จัดรูปแบบให้อัตโนมัติด้วยการตั้งค่าที่เป็นมาตรฐานเดียวกันอยู่แล้ว และเหมือนว่าบริษัทต่าง ๆ ก็ใช้งานกันเยอะนะครับ
 
euphcat 2025-09-10

ประเด็นไม่ใช่การจัดรูปแบบอัตโนมัติ แต่ดูเหมือนว่ากำลังพูดถึงการที่ทั้งแนวคิดว่าการจัดรูปแบบแบบใดแบบหนึ่งเหนือกว่า หรือแม้แต่กระบวนการที่ต้องทิ้งรูปแบบของตัวเองแล้วไปปรับตัวเข้ากับรูปแบบที่ไม่คุ้นเคยนั้น ล้วนเป็นสิ่งที่ไม่จำเป็น เพราะตามตรรกะนี้คือให้เก็บเป็นตัวแทนกลางที่ไม่ยึดติดกับการจัดรูปแบบ แล้วค่อย pretty-print ออกมาตามวิธีที่ผู้ใช้แต่ละคนถนัดได้เอง
 
ndrgrd 2025-09-10

ผมแค่อยากจะสื่อว่า ด้วยการจัดรูปแบบอัตโนมัติ เราก็สามารถทำสิ่งเดียวกันได้ด้วยภาษาที่มีอยู่ในปัจจุบันโดยไม่ต้องมีรูปแบบการเขียนระดับกลาง แต่ดูเหมือนว่าผมอธิบายได้ไม่ชัดพอครับ
 
GN⁺ 2025-09-09
ความคิดเห็นจาก Hacker News
  • ฉันไม่เข้าใจว่าทำไมผู้คนถึงใส่ใจกับการตั้งค่า linter กันมากนัก มันเป็นประเด็นถกเถียงที่ไร้สาระอย่างชัดเจน แค่ตัดสินใจให้เป็นแบบเดียวแล้วรัน linter อัตโนมัติก็จบ เวลาสำหรับทำ software engineering จริง ๆ สำคัญกว่ามาก ไม่ว่าจะใช้ format แบบไหน ถ้าทีมตกลงใช้ร่วมกัน เดี๋ยวก็ชินภายในหนึ่งสัปดาห์
    • มีการชี้ให้เห็นว่า source code formatter กับโปรแกรม lint เป็นคนละอย่างกัน โดย formatter แค่จัด layout ของโค้ด ส่วน linter ช่วยหาบั๊กหรือ error ที่อาจเกิดขึ้นในโค้ด บางเครื่องมือรองรับทั้งสองอย่าง แต่ก็เป็นเพียงรายละเอียดของการ implement สำหรับความหมายของ lint ดูได้ที่ https://en.wikipedia.org/wiki/Lint_(software)
    • ฉันใช้เวลาส่วนใหญ่ไปกับการ “อ่าน” โค้ด และ layout ของโค้ดก็สัมพันธ์กับความเร็วในการอ่านของฉัน ถึงจะปรับตัวกับ layout แบบต่าง ๆ ได้ แต่ไม่ได้แปลว่าทุกแบบจะอ่านง่ายเท่ากัน ฉันจำโค้ดเป็น visual pattern และอ่านโดยแบ่งเป็นส่วน ๆ ตาม layout น่าแปลกที่แม้ฉันจะมี aphantasia คือไม่สามารถนึกภาพในใจได้ แต่กลับจำได้ดีกว่าด้วย visual cue
    • การตั้งค่า linter บางอย่างมีข้อดีชัดเจน เช่น การใช้ trailing comma ในตารางหรือรายการ ทำให้เวลาจะเพิ่มรายการใหม่ในบรรทัดสุดท้ายต้องแก้แค่บรรทัดเดียว และ diff ก็ง่ายขึ้น ดังนั้นการเลือกผิดทำให้ชีวิตฉันยากขึ้น เรื่อง list หรือ include ที่เรียงลำดับก็เหมือนกัน ถ้าไม่ sort ก็มักจะเติมต่อท้ายเสมอ ทำให้ merge conflict เกิดบ่อย เหมือนกับข้อดีของ auto formatter การ sort ก็ควรช่วยประหยัดเวลาด้วย และฉันก็ไวต่อ style ที่ไม่สม่ำเสมอ สิ่งสำคัญที่สุดคือใช้ style เดียวให้สอดคล้องกันทั้งหมด
    • ฉันไม่ได้สนใจ option ยิบย่อยขนาดนั้น แต่คิดว่าการมีค่า linter กลางร่วมกันเป็นสิ่งจำเป็นเพื่อลด noise ไร้สาระเวลาเข้าไปดู PR ฉันรู้สึกว่า git หรือภาษาโปรแกรมต่าง ๆ ที่จัดการได้แค่ระดับบรรทัดนั้นไม่ elegant นัก ตลอด 20 ปีในอาชีพของฉัน ฉันเคยเห็นตัวอย่างที่ใช้วิธีที่ refined กว่านี้จริง ๆ แค่ครั้งเดียว คือภาษา Ada การสร้างอะไรที่ elegant และมีประสิทธิภาพจริงนั้นยาก และถ้ามีทางเลือกที่ดีพออยู่แล้ว ของใหม่ก็ยิ่งแพร่หลายได้ยาก
    • ตอนเด็กกว่านี้ฉันก็เคยติดกับการถกเถียงแบบนี้เหมือนกัน เพราะฉันเคยหลงคิดว่าตัวเองฉลาดที่สุดในทีม คิดว่าความเห็นของฉันสำคัญที่สุด และทุกคนควรฟัง แต่ฉันคิดผิด
  • trade-off ที่ต้องพิจารณาตรงนี้คือ ถ้าใช้ format อย่างอื่นที่ไม่ใช่ text ความสามารถในการใช้เครื่องมือทั่วไปอย่าง grep, diff, sed และ version control จะลดลง สุดท้ายก็ต้องพึ่งเครื่องมือเฉพาะทาง, format เฉพาะ หรือ IDE extension มากขึ้น จุดแข็งของแนวคิดแบบ Unix คือ composability ผ่าน Plain Text มีคำถามหนึ่งที่ตัดประเด็นนี้ได้ง่ายมาก: ถ้าใน editor ทุกคนตั้งความกว้างของช่องว่างแรกเองได้อย่างอิสระ คนที่ชอบ tab จะยังมีเหตุผลอื่นเหลืออีกไหม?
    • แม้แนวทางแบบ text จะมีข้อดี แต่ฉันรู้สึกว่าเราเหมือนปีนลงจากที่ต่ำไปได้แค่นิดเดียว ทั้งที่มีภูเขาที่สูงกว่ารออยู่ คือ projectional editing แต่กลับมัวหลงทางอยู่ข้างล่าง ตัวอย่างทั้งหมดนี้ทำงานได้ดีกว่ามากเมื่อเป็นโค้ดที่มีข้อมูลเชิงโครงสร้าง เช่น การค้นหา symbol ซึ่งฉันใช้บ่อยกว่า text grep มาก สามารถใช้ ast-grep ได้ ส่วน diff ก็รองรับการมองการย้ายเชิงโครงสร้างหรือการละเว้นการเปลี่ยนแปลงที่ไม่มีความหมายได้แบบ semanticdiff.com สำหรับทางเลือกแทน sed ก็ใช้ @codemod/cli ได้ ส่วน version control ก็มีการทดลองมากมายในภาษาอย่าง Unison เพื่อหลีกเลี่ยง conflict จากการเปลี่ยนแปลงที่ไม่มีความหมาย เช่น ลำดับหรือช่องว่าง โดยอัตโนมัติ
    • แนวคิดนี้ถูกพูดถึงซ้ำแล้วซ้ำอีก แต่ในแง่ความคุ้มค่าแล้วมันไม่ค่อยเวิร์ก เพราะแทนที่จะรัน formatter ง่าย ๆ ครั้งเดียว กลับต้องมีเครื่องมือที่ซับซ้อนมาก ทุกคนจะดูโค้ดตามใจชอบจริง ๆ ก็ไม่ได้มีความหมายมากนัก ทุกทีมที่ฉันเคยทำงานด้วยมักตกลงกติกาเดียวกันและบังคับใช้ด้วย formatter แม้ตอนแรกจะไม่เห็นด้วย แต่ไม่นานก็ชิน การถกเถียงเรื่อง formatting เป็นการเสียเวลาชั้นยอด
    • grep, diff, sed และ merge แบบอิงบรรทัด จริง ๆ แล้วเป็นเครื่องมือที่แย่สำหรับการจัดการโค้ด ฉันคิดว่าเราควรคิดถึงเครื่องมือที่ดีกว่านี้มากกว่าจะถกเถียงกันเรื่องเดิม
    • ถ้าเก็บ intermediate representation เป็น text, grep/diff/sed ก็ยังใช้งานได้ทั้งหมด ถ้าใช้ formatter ที่อิง AST อย่างเดียว โค้ดก็จะถูกเก็บในรูปแบบ normalize ตาม AST เฉพาะ แล้ว editor ก็ parse AST ก่อนแสดงผลตาม format ที่ผู้ใช้ต้องการ จากนั้นเวลาบันทึกก็แปลงกลับเป็นรูปแบบ normalize
    • ทั้งระบบปฏิบัติการถูกสร้างขึ้นโดยอาศัย source file แบบนี้ และแนวคิดแบบ Unix ก็จะเปล่งประกายได้จริงก็ต่อเมื่อทุกเครื่องมือคิดถึง plain text และรู้วิธี parse มันเท่านั้น
  • ฉันคิดว่าการจัด format ของ source code มีมิติทาง typography อย่างชัดเจนด้วย และไม่เห็นด้วยกับความคิดที่ว่าเป็นแค่รสนิยมส่วนตัวเท่านั้น การจัด format บางแบบเป็นเครื่องมือที่ถ่ายทอดความหมายและโครงสร้างได้อย่างมีประสิทธิภาพ ถ้าใช้เครื่องมืออัตโนมัติ serialize แค่ token ขั้นต่ำแล้วค่อยกู้คืนกลับมา คุณค่านี้จะหายไป https://naildrivin5.com/blog/2013/05/17/source-code-typograp...
    • ผู้เชี่ยวชาญด้านงานพิมพ์ใช้ความประณีตกับระยะห่างและการจัดแนวของตารางหรือสมการมาอย่างยาวนาน คนภายนอกอาจไม่ค่อยรู้สึก แต่เรื่องพวกนี้สำคัญมาก ฉันคิดว่า source code ก็ยังพัฒนาไปสู่การ formatting ที่ละเอียดขึ้นได้อีก
    • ตัวอย่างเช่น มีคนบ่นว่า Python black formatter มักตัด query ของ SQLAlchemy เป็นหลายบรรทัดมากเกินไปจนความอ่านง่ายกลับแย่ลง
    • ฉันสงสัยมาตลอดว่าทำไมคนจำนวนมากถึงไม่รู้สึกถึงความสำคัญของ typography ในโค้ด
    • ฉันรู้สึกว่าการใส่ใจ typography แต่กลับยอมเดินตามธรรมเนียมของภาษาโปรแกรมอย่างไม่วิจารณ์ เป็นทิศทางที่ผิดที่สุด เช่น วัฒนธรรมที่ยังยอมใช้คำอย่าง register หรือธรรมเนียมที่ใช้เครื่องหมายดอกจัน (*) แทน pointer ทั้งที่สัญลักษณ์หรือคำสงวนแต่ละอย่างสามารถทำให้ intuitive และชัดเจนกว่านี้ได้มาก แต่กลับยืนยันใช้วิธีที่ซับซ้อนและดูยากโดยไม่จำเป็น แม้แต่สัญลักษณ์หรือ reserved word ก็อาจเปลี่ยนเป็นคำที่คุ้นเคยและเป็นธรรมชาติกว่าได้ แต่ผู้คนกลับยึดติดกับจารีตเดิมมากเกินไปจนยอมเสีย readability ไป โดยยกตัวอย่างว่าแม้แต่ฟังก์ชัน strcpy ในโค้ด C ก็สามารถออกแบบใหม่ทั้งหมดด้วยคำและ syntax ที่ชัดเจนและอ่านง่ายกว่าได้
    • มีการอธิบายว่า declaration ของ parameter ใน C ประกอบด้วย modifiers, data type และชื่อ จากนั้นยกตัวอย่างอย่าง char *argv[] เพื่อวิจารณ์ปัญหาความอ่านง่ายของ declaration ที่ซับซ้อน และยังบอกว่า formatting แบบ C++ เช่น char* a, b ก็อาจทำให้เข้าใจผิดได้ จึงคิดว่าควรหลีกเลี่ยง style แบบนั้น
  • ฉันไม่เห็นด้วยกับสมมติฐานตั้งต้นของการถกเถียงนี้ การจัด format โค้ดเป็นเครื่องมือสื่อสารที่สำคัญมาก formatting ที่ดีเป็นสัญญาณว่านักพัฒนา (1) ตระหนักถึงความสำคัญของ formatting (2) ปฏิบัติตามกฎได้ดี (3) มีรสนิยมที่ดี และ (4) มีวิจารณญาณในการรับมือกับกรณียกเว้นได้ดี ทั้งสี่ข้อนี้เป็นความสามารถสำคัญที่ส่งผลเกินกว่าการ formatting ไปถึงศักยภาพการพัฒนาโดยรวม แต่ autoformatter หรือกฎของ linter กลับทำให้สัญญาณเหล่านี้อ่อนลง และเกิดปัญหาแบบกฎของ Goodhart ที่ทำให้หลุดจากเจตนารมณ์เดิม
    • มีการแนะนำว่าบทความบล็อกนั้นสั้นและเรียบง่าย ควรอ่านเองโดยตรง อย่าเพิ่งต่อต้านทันทีเพียงเพราะเห็นชื่อเรื่อง และถ้าเข้าใจบริบทของคำว่า should กับ unnecessary ก็จะช่วยได้
    • ฉันคิดว่าคนที่ไม่สนใจ formatting มักจะเป็นคนที่ (1) ไม่เคยมีประสบการณ์หลายคนแก้ไฟล์เดียวกัน (2) ไม่เคย merge branch (3) ไม่เคยดูแล codebase ขนาดใหญ่ (4) ไม่เคยทำ refactoring ขนาดใหญ่ (5) ไม่เคยค้นประวัติของโค้ดหรือใช้เครื่องมือ diff/เปรียบเทียบ (6) ไม่เคยพัฒนาเครื่องมือ automation สำหรับ codebase หรือ (7) เป็นคนที่สนใจแต่ตัวเองโดยขาดสำนึกในการทำงานร่วมกัน
    • ถ้าคำตอบของรายการเหล่านั้นคือ “ไม่” ทั้งหมด ฉันคิดว่าแค่ทำ formatting อัตโนมัติตอน pass/commit และถ้าไม่ผ่าน automation ก็ให้ CI ขึ้น error ก็เพียงพอแล้ว แทนที่จะหมกมุ่นกับรายละเอียด การใช้ค่าพื้นฐานไปเลยและยอมทิ้ง style ส่วนตัวก็กลับเป็นข้อดี เพราะถ้าปล่อยค่า default ไว้ โค้ดจะดูคุ้นตาสำหรับทุกคนที่เข้ามาอ่าน ยิ่งไปกว่านั้น แม้ formatting กับ linting จะต่างกัน แต่ทั้งสองอย่างก็แก้ด้วยเครื่องมืออัตโนมัติในคราวเดียวได้
    • มีการแซวว่าการประเมินแบบเดียวกันนี้น่าจะใช้กับลายมือได้ด้วย งั้นต่อไปก็ควรให้ส่ง PR เป็นลายมือเขียนเล่น ๆ
    • มีการแนะนำว่าการพึ่ง “รสนิยมในการเลือกกฎ formatting ที่ดี” กลับมีแต่จะก่อให้เกิดการถกเถียงและเสียเวลา มอบหน้าที่นี้ให้ formatter ที่มีมาในตัวแบบ Go หรือ Rust จะดีกว่า
  • ความพยายามที่จะเก็บโค้ดเป็นโครงสร้างไวยากรณ์แล้วให้สิ่งที่มนุษย์เห็นเป็นเพียงผลลัพธ์จากการ render มีมาตั้งแต่ 20–25 ปีก่อนแล้ว เป็นกระแสที่เริ่มมาตั้งแต่ยุค 90 เมื่อ refactoring เริ่มฮิต IDE อย่าง Visual Age เคยใช้โมเดลที่เก็บโค้ดไว้ในฐานข้อมูลแทน file system แนวคิดอย่าง intentional programming หรือ model-driven development ก็เป็นส่วนหนึ่งของวัฏจักรนี้ แก่นแท้ของ refactoring คือการแปลง AST ทำให้การเปลี่ยนชื่อ symbol ง่ายมากและไม่จำเป็นต้องไปหาแทนที่ใน source code โดยตรง แต่ผู้คนยังคุ้นกับการแก้ไฟล์ และยังมีแรงต้านกับแนวทางที่เก็บโครงสร้างโดยตรง ทำให้มันไม่แพร่หลาย การที่เวลาผ่านไปนานแล้วเรายังต้องถกเรื่อง formatting ก็ยิ่งชี้ว่าทางเลือกนี้ยังจำเป็น และแม้แต่การ rename symbol แบบ robust ในระดับภาษา/editor เองก็ยังมีให้เห็นบ่อยว่าทำได้ไม่ดีพอ
    • มีความเห็นว่านี่เป็นการปะปน abstraction layer กัน เพราะ AST สุดท้ายก็ต้องถูกเก็บลงไฟล์อยู่ดี จึงไม่ได้ต่างจากการใช้เครื่องมือที่เข้าใจ AST กับไฟล์ที่มนุษย์อ่านได้มากนัก format ที่ใช้เก็บอาจไม่ได้สำคัญขนาดนั้น แก่นจริง ๆ คือเรื่องของเครื่องมือที่ฉลาดกว่า โดยยกตัวอย่าง Microsoft Roslyn หรือทิศทางที่ compiler สมัยใหม่พยายามเปิด API ให้โต้ตอบกับ codebase ได้
  • มีการยกตัวอย่างโดยตรงว่า formatting บางอย่างไม่สามารถสรุปได้จาก AST เพียงอย่างเดียว เช่น เมื่อมีโค้ด assignment หลายบรรทัด จะจัดให้สามบรรทัดเรียงตรงกันทั้งหมด, จัดตามเครื่องหมาย =, หรือใส่ tab เพื่อเน้นระดับความลึกของโครงสร้างก็ได้ ถ้าต้องการเน้นค่าก็อาจจัดตัวเลขชิดขวา แต่ถ้าต้องการเน้นโครงสร้างก็อาจจัด member variable ให้ตรงกันเพื่อให้อ่านง่ายขึ้น มุมที่ผู้เขียนต้องการเน้นในโค้ดอาจต่างกัน และถ้าไม่มี metadata เพิ่มเติม ข้อมูลพวกนี้ก็สกัดจาก AST ไม่ได้
    • ฉันเข้าใจว่าหมายถึงอะไร แต่ในทางปฏิบัติก็ใช้กันจริงแค่สองแบบแรก จุดประสงค์จริงไม่ใช่การเน้น แต่คือความอ่านง่าย แม้จะมีบางอย่างสูญหายไปตอนแปลงเป็น AST แต่ฉันคิดว่าสิ่งที่ได้กลับมามีมากกว่ามาก และยังสามารถทำตัวแปลงเพื่อเก็บการเน้นไว้ใน AST ได้ด้วย เช่น setValue([bar, glob], 1) หรือ syntax แบบ comment สำหรับ style override ก็รองรับได้หลากหลาย
    • “การจัด format โค้ดที่พึงประสงค์” สุดท้ายก็เป็นเรื่อง主观 เช่น ในตัวอย่าง คนหนึ่งอาจชอบ 2/4/8 ช่องว่าง อีกคนอาจชอบการจัดแนวตามคอลัมน์ AST ไม่มีข้อมูล formatting ของ source code อยู่แล้ว จึง derive อัตโนมัติไม่ได้
    • ตัวอย่าง formatting แบบที่สองและสาม จริง ๆ แล้วเป็นปัญหาด้านการออกแบบเชิงโครงสร้าง เช่น การละเมิด Law of Demeter มากกว่า ไม่ใช่เรื่องของ formatting
  • Projectional Editing สามารถใช้กับ text source ได้เช่นกัน มีวิดีโอตัวอย่างของ JetBrains MPS ที่ render ตารางออกมาจากโค้ด https://www.youtube.com/watch?v=XolJx4GfMmg&t=63s และมีความต้องการให้ IDE render dictionary เป็นตาราง ปัจจุบันก็มีฟีเจอร์คล้าย ๆ กันอยู่แล้วบางส่วน เช่น code folding, inlay hint, และ docstring ที่ render เป็น HTML https://x.com/efortis/status/1922427544470438381
  • มีการนิยามว่าเรายังมีข้อจำกัดที่รับสิ่งซึ่ง abstract กว่า plain text ไม่ได้ในตอนนี้ ต่อให้พยายามอย่างไร สุดท้ายก็ถูกลดทอนกลับเป็น projection ของ plain text มองว่า “giant lookup table (GLUT)” ที่สะสมมาตั้งแต่ Morse Code จนถึง Unicode เป็นสิ่งที่สร้างวัฒนธรรมการถอดรหัสสัญลักษณ์แบบทุกวันนี้ เมื่อยกระดับ abstraction ขึ้น ก็จะสร้างชุดสัญลักษณ์ที่เหมาะกับแอปพลิเคชันมากขึ้น แต่เครื่องมือที่สอดคล้องกันกลับไม่เกิดขึ้น สุดท้ายก็ต้องแปลงกลับเป็นการส่ง text แล้ว parse กันอีกที เช่น CSV หรือ Markdown แม้ XML จะมี editor เฉพาะทางออกมาเรื่อย ๆ แต่คนก็ยังอยากแก้ด้วย plain text อยู่ดี อย่างไรก็ตาม เรื่องนี้ก็ไม่ได้เป็นบวกทั้งหมด เพราะยังมีปัญหาอย่าง character encoding หรืออักขระพิเศษด้วย
  • บางครั้งฉันก็สงสัยว่าทำไม artifact ที่เก็บไว้กับ projection ของโค้ดที่เราเห็นจริงต้องเป็นสิ่งเดียวกัน แม้แต่ git diff เองก็น่าจะดีถ้าดูในรูปแบบ projection ของ IR (intermediate representation) ได้ ด้วยการมาของเครื่องมือ AST อย่าง treesitter ทำให้เริ่มจินตนาการถึง interface ที่ช่วยให้มนุษย์จัดการ AST หรือ IR ได้มีประสิทธิภาพขึ้น ยกตัวอย่างว่าโครงสร้าง ordered compilation ของ F# ช่วยให้ code review ง่ายขึ้น แต่ในภาษา/โครงสร้างที่ยอมให้ลำดับเป็นอิสระ เวลาจะดู diff เล็ก ๆ ทีหนึ่งกลับต้องวิ่งไปดูหลายจุดเพื่อทำความเข้าใจบริบททั้งหมดของการเปลี่ยนแปลง ซึ่งยุ่งยากมาก
  • มีการแชร์ความไม่สะดวกเกี่ยวกับ eslint-config-airbnb โดยยก issue เด่น ๆ เช่น #1271, #1122 มีการเสียเวลาเกินหนึ่งชั่วโมงพยายามนำ airbnb config ไปใช้กับโปรเจกต์เดิม ทั้งที่โค้ดเดิมก็สมบูรณ์ดีอยู่แล้ว แต่กลับไม่ productive เพราะกฎที่ไม่จำเป็น สุดท้ายเลยปิดกฎนั้นเฉพาะใน local และหลังจากนั้นก็ไม่ใช้อีกเลยกับโปรเจกต์ไหน เรื่องนี้เป็นตัวอย่างว่ากฎ lint ที่แย่สามารถทำลาย productivity ได้มากแค่ไหน