ในโลกของอินเทอร์เฟซแบบคำสั่ง (command-line interfaces) ความสม่ำเสมอและการคาดเดาได้เป็นสิ่งสำคัญอย่างยิ่ง แพ็คเกจ Go ใหม่ที่เรียกว่า argp ได้ปรากฏขึ้นเมื่อไม่นานมานี้ โดยสัญญาว่าจะให้บริการตัวแยกวิเคราะห์อาร์กิวเมนต์บรรทัดคำสั่งตามมาตรฐาน GNU อย่างไรก็ตาม การเปิดตัวของมันได้จุดประเด็นการอภิปรายอย่างมีนัยสำคัญในหมู่นักพัฒนาเกี่ยวกับมาตรฐาน CLI ข้อกังวลเรื่องความเข้ากันได้ และความตึงเครียดที่มีอยู่ระหว่างการปฏิบัติตามแนวทางที่มีอยู่เดิมกับการแนะนำแนวทางใหม่ๆ
การต่อสู้ของมาตรฐาน CLI
การแนะนำตัวแยกวิเคราะห์ใหม่นี้ได้จุดประเด็นการถกเถียงที่มีมายาวนานเกี่ยวกับมาตรฐานอินเทอร์เฟซบรรทัดคำสั่งที่นักพัฒนาควรปฏิบัติตาม ในขณะที่แพ็คเกจนี้อ้างว่าได้ใช้การแยกวิเคราะห์อาร์กิวเมนต์แบบ GNU ผู้แสดงความคิดเห็นหลายคนได้ชี้ให้เห็นถึงความไม่สอดคล้องกับมาตรฐาน GNU ที่แท้จริง ความเบี่ยงเบนที่โดดเด่นคือการจัดการกับค่าหลายค่าสำหรับตัวเลือก เอกสารประกอบของแพ็คเกจแนะนำว่า -a 1 2 3
จะกำหนดค่าทั้งสามให้กับตัวเลือก a ในขณะที่สไตล์ GNU แบบดั้งเดิมจะตีความว่าเป็นตัวเลือก a ที่มีค่า 1 ตามด้วยอาร์กิวเมนต์ตำแหน่งสองตัว
โดยทั่วไปแล้ว ตัวแยกวิเคราะห์อาร์กิวเมนต์บรรทัดคำสั่งควรปฏิบัติตามสไตล์ GNU ไม่มากไปกว่านี้และไม่น้อยกว่านี้ การเบี่ยงเบนทำให้ผู้ใช้สับสนเพราะไม่ชัดเจนทันทีสำหรับพวกเขาว่าตัวแยกวิเคราะห์กำลังบังคับใช้กฎอะไร
ความรู้สึกนี้สะท้อนถึงความคับข้องใจทั่วไปในหมู่นักพัฒนาที่ต้องนำทางพฤติกรรม CLI ที่ไม่สอดคล้องกันในเครื่องมือต่างๆ มาตรฐาน POSIX ซึ่งมีมาก่อนแนวทางปฏิบัติของ GNU มีข้อจำกัดมากกว่าและไม่ได้กำหนดตัวเลือกแบบยาวเลย สิ่งนี้นำไปสู่ภูมิทัศน์ที่แตกแยกซึ่งชุมชนต่างๆ (Go, Python, Java) ได้พัฒนาแนวทาง CLI ของตนเอง ซึ่งมักสร้างความผิดหวังให้กับผู้ใช้ที่คาดหวังพฤติกรรมที่สอดคล้องกัน
เครื่องมือแยกวิเคราะห์คำสั่งบรรทัดคำสั่งยอดนิยมใน Go
- Standard library flag: ตัวเลือกแบบง่ายในสไตล์ Go (
-flag=value
) - Cobra/pflag: ตัวเลือกแบบ GNU พร้อมการรองรับการเติมคำอัตโนมัติ
- Kong: ฟังก์ชันขั้นสูงเช่นกลุ่มตัวเลือกและการเชื่อมโยงตัวแปรสภาพแวดล้อม
- urfave/cli: ทางเลือกยอดนิยมที่มีประสบการณ์นักพัฒนาที่ดี
- go-flags: วิธีการแบบโครงสร้างโดยใช้แท็ก
- argp: ตัวแยกวิเคราะห์แบบ GNU ใหม่ที่รองรับแท็กโครงสร้าง
กฎการใช้บรรทัดคำสั่งแบบ GNU
- อาร์กิวเมนต์เป็นตัวเลือกเมื่อขึ้นต้นด้วยเครื่องหมายขีด
-
- ตัวเลือกสั้นหลายตัวสามารถรวมกันได้:
-abc
เท่ากับ-a -b -c
- ตัวเลือกแบบยาวขึ้นต้นด้วยขีดสองขีด:
--verbose
- ค่าของตัวเลือกสามารถแยกด้วยช่องว่าง เครื่องหมายเท่ากับ หรือไม่มีอะไรเลย
- ตัวเลือกและสิ่งที่ไม่ใช่ตัวเลือกสามารถสลับกันได้
--
จะยุติตัวเลือกทั้งหมด- เครื่องหมาย
-
เดี่ยวจะถูกปฏิบัติเหมือนสิ่งที่ไม่ใช่ตัวเลือก
ข้อกังวลเรื่องความเข้ากันได้และกรณีพิเศษ
ประเด็นที่มีการโต้เถียงกันอย่างรุนแรงที่ถูกหยิบยกขึ้นมาในการอภิปรายเกี่ยวข้องกับการจัดการเครื่องหมายเท่ากับในตัวเลือกสั้น เอกสารประกอบของแพ็คเกจระบุว่า -a=1
เทียบเท่ากับ -a 1
แต่สิ่งนี้สามารถสร้างปัญหากับเครื่องมือเช่น cut
ซึ่ง -d=
เป็นรูปแบบการใช้งานทั่วไป หากเครื่องหมายเท่ากับถูกกลืนโดยตัวแยกวิเคราะห์ มันจะเปลี่ยนพฤติกรรมในวิธีที่อาจทำให้เกิดความเสียหายได้
สิ่งนี้เน้นย้ำความท้าทายที่กว้างขึ้น: ความเข้ากันได้ย้อนหลัง สคริปต์เชลล์และเวิร์กโฟลว์ของผู้ใช้ที่พึ่งพาพฤติกรรม CLI เฉพาะมาเป็นทศวรรษสามารถเสียหายได้เมื่อเครื่องมือใหม่ใช้กฎการแยกวิเคราะห์ที่แตกต่างกัน ผู้แสดงความคิดเห็นหลายคนได้แบ่งปันตัวอย่างจากโลกจริงที่ความไม่สอดคล้องเหล่านี้ได้สร้างปัญหา เช่น ในการจัดการแพ็คเกจ Gentoo ที่ชื่อแพ็คเกจที่แน่นอนต้องขึ้นต้นด้วยเครื่องหมายเท่ากับ
ระบบนิเวศของตัวแยกวิเคราะห์บรรทัดคำสั่ง
การอภิปรายเผยให้เห็นว่าชุมชน Go มีตัวแยกวิเคราะห์บรรทัดคำสั่งที่เป็นที่ยอมรับหลายตัวแล้วด้วยแนวทางและชุดคุณสมบัติที่แตกต่างกัน Cobra (พร้อม pflag), Kong และ urfave/cli ถูกกล่าวถึงบ่อยครั้งว่าเป็นทางเลือกที่เติบโตเต็มที่แล้ว แต่ละตัวมีจุดแข็งของตัวเอง – Cobra มีการเติมเต็มเชลล์อัตโนมัติ, Kong จัดการกับอินเทอร์เฟซ CLI ที่ซับซ้อนได้ดี และ go-flags ให้แนวทางที่อิงโครงสร้างคล้ายกับแพ็คเกจใหม่
การแตกแยกนี้ทำให้เกิดคำถามว่าจำเป็นต้องมีตัวแยกวิเคราะห์อีกตัวหรือไม่ โดยเฉพาะอย่างยิ่งตัวที่แนะนำการตีความมาตรฐาน GNU ของตัวเอง นักพัฒนาบางคนแสดงความคับข้องใจที่แพ็คเกจ flag ในไลบรารีมาตรฐานของ Go ไม่ได้ปฏิบัติตามแนวทาง GNU ในขณะที่คนอื่นๆ ปกป้องแนวทางที่เรียบง่ายกว่าของ Go ว่ามีความสอดคล้องมากกว่าภายในระบบนิเวศของตัวเอง
การสะท้อนและข้อพิจารณาด้านประสิทธิภาพ
ข้อกังวลทางเทคนิคที่นักพัฒนาบางคนหยิบยกขึ้นมาคือการใช้แท็กโครงสร้างและการสะท้อน (reflection) ในตัวแยกวิเคราะห์ใหม่ ในขณะที่แนวทางนี้ช่วยให้สามารถกำหนดตัวเลือกบรรทัดคำสั่งในสไตล์เชิงประกาศที่สะอาด แต่ก็มาพร้อมกับข้อเสียที่อาจเกิดขึ้น การสะท้อนสามารถส่งผลต่อประสิทธิภาพและปิดใช้งานการกำจัดโค้ดที่ไม่ได้ใช้ระหว่างการคอมไพล์ ซึ่งอาจนำไปสู่ขนาดไบนารีที่ใหญ่ขึ้น นอกจากนี้ยังย้ายการตรวจสอบความถูกต้องจากเวลาคอมไพล์ไปเป็นเวลารันไทม์ ซึ่งนักพัฒนาบางคนถือว่าเป็นปัญหา
การถกเถียงเกี่ยวกับแท็กโครงสร้างเน้นย้ำถึงความตึงเครียดที่กว้างขึ้นในการพัฒนา Go ระหว่างการปฏิบัติตามรูปแบบที่เป็นเอกลักษณ์และการปรับประสิทธิภาพและความปลอดภัย ในขณะที่แพ็คเกจ Go ยอดนิยมหลายตัวใช้การสะท้อนและแท็กโครงสร้าง (เช่น encoding/json) นักพัฒนาบางคนชอบโค้ดที่ชัดเจนมากกว่าพฤติกรรมเวลารันไทม์ที่เป็นเหมือนเวทมนตร์
ในท้ายที่สุด การอภิปรายเกี่ยวกับตัวแยกวิเคราะห์บรรทัดคำสั่งใหม่นี้สะท้อนถึงความท้าทายอย่างต่อเนื่องของการสร้างสมดุลระหว่างการปฏิบัติตามมาตรฐาน ความคาดหวังของผู้ใช้ และลักษณะเฉพาะของภาษา แม้ว่าการมีตัวเลือกจะมีคุณค่า แต่การแพร่หลายของแนวทางที่แตกต่างกันเล็กน้อยในการแยกวิเคราะห์ CLI ยังคงสร้างความขัดแย้งสำหรับทั้งนักพัฒนาและผู้ใช้ ดังที่ผู้แสดงความคิดเห็นคนหนึ่งได้กล่าวไว้ บางทีสิ่งที่สำคัญที่สุดอาจไม่ใช่มาตรฐานไหนดีที่สุด แต่เป็นว่าเครื่องมือต่างๆ ปฏิบัติตามมาตรฐานบางอย่างอย่างสม่ำเสมอที่ผู้ใช้สามารถพึ่งพาได้
อ้างอิง: GNU command line argument parser