Những thói quen tốt để thiết kế đối số dòng lệnh là gì?

Trong khi phát triển ứng dụng, tôi bắt đầu tự hỏi - Tôi nên thiết kế các đối số dòng lệnh như thế nào?

Rất nhiều chương trình đang sử dụng công thức như thế này -argument valuehoặc /argument value. Giải pháp mà đến tâm trí của tôi là argument:value. Tôi nghĩ rằng nó là tốt bởi vì không có khoảng trắng, không có cách nào mà các giá trị và đối số có thể bị rối tung. Ngoài ra, thật dễ dàng để chia một chuỗi thành hai trên đầu tiên từ :ký tự bên trái .

Câu hỏi của tôi là:

1. Là -argument valuecông thức phổ biến tốt hơn argument:value(dễ đọc hơn, dễ viết hơn, không có lỗi, dễ hiểu hơn bởi các nhà phát triển chuyên gia)?
2. Có một số quy tắc thường được biết mà tôi nên tuân theo trong khi thiết kế các đối số dòng lệnh (trừ khi nó hoạt động thì nó vẫn ổn)?

Hỏi thêm một số chi tiết tôi sẽ cung cấp nó. Tuy nhiên tôi nghĩ họ không nên ảnh hưởng đến câu trả lời. Câu hỏi là về một thói quen tốt nói chung. Tôi nghĩ rằng tất cả chúng đều giống nhau cho tất cả các loại ứng dụng.

Chúng tôi đang làm việc trên một ứng dụng sẽ được sử dụng ở những nơi công cộng (chạm totems, bảng). Các ứng dụng được viết bằng Qt Quick 5 (C ++, QML, JS). Các thiết bị sẽ được cài đặt Windows 8.1 / 10. Chúng tôi sẽ cung cấp giao diện front-end để quản lý các thiết bị. Tuy nhiên, một số quản trị viên nâng cao có thể muốn tự cấu hình ứng dụng. Điều này không quan trọng lắm từ phía doanh nghiệp nhưng như tôi đồng ý với những gì Kilian Foth nói, tôi không muốn ứng dụng của mình trở thành nỗi đau cho người dùng. Không tìm thấy trên Internet những gì tôi muốn tôi đã hỏi ở đây.

Đối với người dùng Stack Exchange nâng cao hơn: Tôi muốn câu hỏi này là chung chung. Có lẽ nó đủ điều kiện cho wiki cộng đồng (Tôi không biết câu hỏi hiện tại có thể được chuyển đổi bằng câu trả lời không). Vì tôi muốn câu hỏi này là hệ điều hành và ngôn ngữ lập trình độc lập, các câu trả lời xuất hiện ở đây có thể là một bài học quý giá cho các nhà phát triển khác.

Trên các hệ thống POSIX (ví dụ Linux, MacOSX), ít nhất là đối với các chương trình có thể bắt đầu trong thiết bị đầu cuối shell (ví dụ: hầu hết trong số chúng), tôi khuyên bạn nên sử dụng các quy ước mã hóa GNU (cũng liệt kê các tên đối số phổ biến) và xem xét các hướng dẫn về tiện ích POSIX , ngay cả đối với phần mềm độc quyền:

• luôn luôn xử lý --versionvà--help (thậm chí /bin/truechấp nhận chúng !!). Tôi nguyền rủa các tác giả của phần mềm không hiểu --help, tôi ghét họ (vì đó prog --help là lệnh đầu tiên tôi đang thử trên một chương trình mới)! Thường --helpcó thể được viết tắt là-h

• Có --helpthông báo liệt kê tất cả các tùy chọn (trừ khi bạn có quá nhiều trong số chúng ... trong trường hợp đó liệt kê các tùy chọn phổ biến nhất và tham chiếu rõ ràng đến một số mantrang hoặc một số URL) và các giá trị mặc định của các tùy chọn, và có lẽ quan trọng (và cụ thể theo chương trình ) biến môi trường. Hiển thị các danh sách tùy chọn về lỗi đối số tùy chọn.

• chấp nhận -ađối số ngắn (đơn thư) và có một số tương đương --long-argument, vì vậy -a2 --long-argument=2, --long-argument 2; tất nhiên bạn có thể có (cho các tùy chọn hiếm khi được sử dụng) một số --only-long-argumenttên; đối với các đối số phương thức mà không có tùy chọn bổ sung -cfthường được xử lý như -c -f, v.v. vì vậy -argument:valueđề xuất của bạn là lạ và tôi không khuyên bạn nên làm điều đó.

• sử dụng GLIBC getopt_long hoặc tốt hơn (ví dụ: argp_parse , trong Argmô-đun OCaml , ...)

• thường sử dụng -cho đầu vào hoặc đầu ra tiêu chuẩn (nếu bạn không thể làm điều đó, xử lý /dev/stdin& /dev/stdoutthậm chí trên một số hệ điều hành không có chúng)

• bắt chước hành vi của các chương trình tương tự bằng cách sử dụng lại hầu hết các quy ước tùy chọn của chúng; đặc biệt -ncho chạy khô (à la make), -hđể được giúp đỡ, -vcho sự dài dòng, v.v ...

• sử dụng --như dấu phân cách giữa các tùy chọn & tệp hoặc các đối số khác

• nếu chương trình của bạn sử dụng isattyđể kiểm tra hơn stdin là thiết bị đầu cuối (và hoạt động "tương tác" trong trường hợp đó), hãy cung cấp tùy chọn để buộc chế độ không tương tác, tương tự nếu chương trình của bạn có giao diện GUI (và kiểm tra getenv("DISPLAY")trên máy tính để bàn X11) nhưng cũng có thể được sử dụng trong lô hoặc dòng lệnh.

• Một số chương trình (ví dụ gcc) chấp nhận danh sách đối số gián tiếp, @somefile.txtcó nghĩa là đọc các đối số chương trình từ somefile.txt; điều này có thể hữu ích khi chương trình của bạn có thể chấp nhận rất nhiều đối số (nhiều hơn so với kernel của bạn ARG_MAX)

BTW, bạn thậm chí có thể thêm một số tiện ích tự động hoàn thành cho chương trình của mình và các shell thông thường (như bashhoặc zsh)

Một số lệnh Unix cũ (ví dụ dd, hoặc thậm chí sed) có các đối số lệnh lạ để tương thích lịch sử. Tôi khuyên bạn không nên theo thói quen xấu của họ (trừ khi bạn đang thực hiện một số biến thể tốt hơn của họ).

Nếu phần mềm của bạn là một loạt các chương trình dòng lệnh có liên quan, lấy cảm hứng từ git (mà bạn chắc chắn sử dụng như một công cụ phát triển), mà chấp nhận git helpvà git --helpvà có nhiều gitsubcommandvàgitsubcommand--help

Trong những trường hợp hiếm hoi, bạn cũng có thể sử dụng argv[0](bằng cách sử dụng liên kết tượng trưng trên chương trình của mình), ví dụ như bashđược gọi là rbashcó hành vi khác ( vỏ bị hạn chế ). Nhưng tôi thường không khuyên bạn nên làm điều đó; nó có thể có ý nghĩa nếu chương trình của bạn có thể được sử dụng như một trình thông dịch kịch bản bằng cách sử dụng shebang tức là #!trên dòng đầu tiên được thực hiện bởi execve (2) . Nếu bạn làm những thủ thuật như vậy, hãy chắc chắn ghi lại chúng, kể cả trong --helptin nhắn.

Hãy nhớ rằng trên POSIX các vỏ được globbing đối số ( trước khi chạy chương trình của bạn!), Do đó tránh đòi hỏi nhân vật (như *hay $hay ~) trong các tùy chọn mà sẽ cần phải được vỏ thoát.

Trong một số trường hợp, bạn có thể nhúng trình thông dịch như GNU guile hoặc Lua vào phần mềm của bạn (tránh phát minh ngôn ngữ kịch bản hoàn chỉnh Turing của riêng bạn nếu bạn không phải là chuyên gia về ngôn ngữ lập trình). Điều này có hậu quả sâu sắc đối với việc thiết kế phần mềm của bạn (vì vậy nên nghĩ đến sớm!). Sau đó, bạn có thể dễ dàng chuyển một số tập lệnh hoặc một số biểu thức cho trình thông dịch đó. Nếu bạn thực hiện phương pháp thú vị đó, hãy cẩn thận thiết kế phần mềm và phần mềm được giải thích; bạn có thể có một số người dùng kỳ lạ mã hóa các tập lệnh lớn cho việc của bạn.

Trong các trường hợp khác, bạn có thể muốn cho phép người dùng nâng cao của mình tải plugin của họ vào phần mềm của bạn (sử dụng các kỹ thuật tải động à la dlopen& dlsym). Một lần nữa, đây là một quyết định thiết kế rất quan trọng (vì vậy hãy xác định và ghi lại giao diện plugin một cách cẩn thận) và bạn sẽ cần xác định một quy ước để chuyển các tùy chọn chương trình cho các plugin này.

Nếu phần mềm của bạn là một thứ phức tạp, hãy làm cho nó chấp nhận một số tệp cấu hình (ngoài hoặc thay thế các đối số chương trình) và có thể có một số cách để kiểm tra (hoặc chỉ phân tích) các tệp cấu hình này mà không chạy tất cả mã. Ví dụ, một tác nhân chuyển thư (như Exim hoặc Postfix) khá phức tạp và rất hữu ích khi có thể "làm khô" nó (ví dụ: quan sát cách xử lý một số địa chỉ email đã cho mà không thực sự gửi email).

^{Lưu ý rằng đó /optionlà một điều Windows hoặc VMS. Nó sẽ là điên rồ trên các hệ thống POSIX (vì hệ thống phân cấp tệp sử dụng /như một bộ tách thư mục và vì shell thực hiện việc tạo khối). Tất cả câu trả lời của tôi chủ yếu dành cho Linux (và POSIX).}

PS Nếu có thể, hãy biến chương trình của bạn thành một phần mềm miễn phí , bạn sẽ nhận được những cải tiến từ một số người dùng và nhà phát triển (và thêm tùy chọn chương trình mới thường là một trong những điều dễ nhất để thêm vào phần mềm miễn phí hiện có). Ngoài ra, câu hỏi của bạn phụ thuộc rất nhiều vào đối tượng dự định : trò chơi dành cho thanh thiếu niên hoặc trình duyệt dành cho bà có lẽ không cần cùng loại và số lượng tùy chọn so với trình biên dịch hoặc trình kiểm tra mạng cho sysadins của trung tâm dữ liệu hoặc phần mềm CAD cho bộ vi xử lý kiến trúc sư hoặc cho các nhà thiết kế cầu. Một kỹ sư quen thuộc với lập trình & viết kịch bản có thể thích nhiều tùy chọn có thể điều chỉnh hơn so với bà của bạn và có thể muốn chạy ứng dụng của bạn mà không cần X11 (có thể trong một crontabcông việc).

Thực tế là một quy ước định dạng dữ liệu là phổ biến là lợi thế của nó.

Bạn có thể dễ dàng thấy rằng sử dụng = hoặc: hoặc thậm chí '' làm dấu phân cách là những khác biệt nhỏ có thể được chuyển đổi lẫn nhau bằng máy tính với ít nỗ lực. Điều gì sẽ là một nỗ lực lớn để con người ghi nhớ "Bây giờ hãy xem, chương trình được sử dụng không thường xuyên này có phân định mọi thứ bằng :hoặc với =? Hmmm ..."

Nói cách khác, vì tình yêu của chúa, đừng đi chệch khỏi những quy ước cực kỳ cố thủ mà không có lý do thuyết phục. Mọi người sẽ nhớ chương trình của bạn là "chương trình có cú pháp cmdline kỳ lạ và khó chịu" thay vì "chương trình đã lưu bài luận đại học của tôi".

Trong điều khoản của Giáo dân

Nhập gia tùy tục.

• Nếu ứng dụng CLI của bạn dành cho Linux / Unix, hãy sử dụng -p valuehoặc --parameter valuequy ước. Linux có các công cụ để phân tích các tham số và cờ như vậy một cách dễ dàng.

Tôi thường làm một cái gì đó như thế này:

while [[ $# > 0 ]]
do
key="$1"
case $key in
    --dummy)
    #this is a flag do something here
    ;;
    --audit_sessiones)
    #this is a flag do something here
    ;;
    --destination_path)
    # this is a key-value parameter
    # the value is always in $2 , 
    # you must shift to skip over for the next iteration
    path=$2
    shift
    ;;
    *)
    # unknown option
    ;;
esac
shift
done

• Nếu ứng dụng CLI của bạn dành cho Windows, thì hãy sử dụng /flagvà /flag:valuequy ước.

• Một số ứng dụng như Oracle không sử dụng. Sử dụng tiện ích Oracle PARAMETER=VALUE.

• Một điều tôi muốn làm là, ngoài việc chấp nhận các tham số trong dòng lệnh, cung cấp tùy chọn sử dụng một tệp con , đó là một tệp cặp giá trị khóa để tránh các chuỗi tham số dài. Cho rằng bạn nên cung cấp một --parfile mifile.partham số bổ sung . Rõ ràng nếu --parfileđược sử dụng, tất cả các tham số khác sẽ bị loại bỏ theo hướng có lợi cho những gì bên trong thư mục.

• Một đề xuất bổ sung là cho phép sử dụng một số biến môi trường tùy chỉnh , ví dụ, đặt biến môi trường MYAPP_WRKSPACE=/tmpsẽ khiến nó không cần thiết phải luôn được đặt --wrkspace /tmp.

• Trong Linux, đừng quên thêm tự động hoàn thành tham số , nghĩa là người dùng có thể gõ một nửa công tắc, nhấn TABvà sau đó shell sẽ hoàn thành nó cho họ.

Một điều chưa được đưa ra:

Cố gắng thiết kế phần mềm của bạn từ các đối số dòng lệnh trở lên. Ý nghĩa:

Trước khi thiết kế các chức năng, thiết kế giao diện người dùng.

Điều này sẽ cho phép bạn đi sâu vào các trường hợp cạnh và các trường hợp phổ biến sớm. Tất nhiên bạn sẽ vẫn trừu tượng bên ngoài và bên trong, nhưng nó sẽ mang lại kết quả tốt hơn nhiều so với việc chỉ viết tất cả mã và sau đó đập CLI vào nó.

Hơn nữa, hãy xem docopt ( http://docopt.org/ ).

docopt là một trợ giúp tuyệt vời với nhiều ngôn ngữ, đặc biệt là đối với python, nơi bạn bị hạn chế nghiêm trọng, các trình phân tích đối số bất lợi cho người dùng như argparse vẫn được coi là "OK". Thay vì có các trình phân tích cú pháp và các bộ con và các ký tự điều kiện, bạn chỉ cần xác định trợ giúp cú pháp và phần còn lại sẽ thực hiện.

Một số ý kiến ​​có giá trị đã được cung cấp (@Florian, Basile), nhưng hãy để tôi thêm ... OP nói,

Chúng tôi sẽ cung cấp giao diện front-end để quản lý các thiết bị. Tuy nhiên, một số quản trị viên nâng cao có thể muốn tự cấu hình ứng dụng

Nhưng cũng nhận xét:

Tôi không muốn câu hỏi này là nền tảng hoặc ngôn ngữ cụ thể

Bạn phải xem xét đối tượng mục tiêu của mình - quản trị viên nâng cao . Nền tảng nào họ thường làm việc trên - Win / Unix / Mac? Và ứng dụng bạn chạy trên nền tảng nào? Thực hiện theo bất kỳ quy ước CLI nào đã được thiết lập cho nền tảng đó. Các quản trị viên "nâng cao" của bạn có muốn / cần một công cụ dựa trên GUI không?

Bạn muốn giao diện nhất quán trong nội bộ và với các công cụ quản trị khác. Tôi không muốn phải dừng lại và nghĩ là nó cmd -p <arg>hay cmd -p:<arg>hay cmd /p <arg>. Tôi có cần trích dẫn 'vì có một không gian? Tôi có thể cmd -p <val1> <val2>hoặc cmd -p <val1> -p <val2>cho nhiều mục tiêu? Họ có đặt hàng cụ thể không? Quá tải? Có cmd -p2 <arg> -p1 <arg>làm việc quá không? Có ls -l -r -t dir1 dir2== ls -trl dir1 dir2?

Đối với các công cụ quản trị Unix của tôi, tôi luôn ghi nhớ hướng dẫn được cung cấp bởi Shellerorado của Heiner cùng với các tài liệu tham khảo khác được đề cập.

Quan trọng như việc thiết kế CLI là đảm bảo ứng dụng của bạn được thiết kế để hoạt động với các đối số dòng lệnh giống như từ GUI - tức là: không có logic nghiệp vụ trong GUI hoặc sử dụng lệnh chung được gọi từ cả GUI và CLI.

Hầu hết các công cụ quản trị dựa trên UNIX thực sự được thiết kế đầu tiên dưới dạng các công cụ dòng lệnh và GUI được cung cấp chỉ đơn giản tạo điều kiện "điền" các tùy chọn cho dòng lệnh. Cách tiếp cận đó cho phép tự động hóa, sử dụng các tệp phản hồi, v.v. và quản lý thực hành (công việc ít hơn đối với tôi!)

Vì bộ công cụ cổ điển được sử dụng với phương pháp này là Tcl / Tk . Không đề nghị bạn chuyển đổi công cụ; chỉ cần xem xét phương pháp thiết kế từ việc viết một ứng dụng quản trị dựa trên GUI cho ứng dụng như một công cụ dòng lệnh trước tiên; sau đó lớp GUI lên trên để thuận tiện. Tại một số điểm, bạn có thể sẽ phát hiện ra GUI là một vấn đề khó khăn (và dễ bị lỗi) nếu bạn phải thực hiện nhiều cấu hình và nhập lại các tùy chọn chung lặp đi lặp lại và bạn sẽ tìm cách tiếp cận tự động.

Hãy nhớ rằng quản trị viên của bạn có thể phải nhập các giá trị chính xác vào các ô chính xác, vì vậy dù sao bạn cũng sẽ giải quyết được bao nhiêu nỗ lực w / GUI?