Consider the following command-line program manage-id
. It does these things:
manage-id list (list all usernames and user-ids)
manage-id show <username> (shows username's id)
manage-id clear <username> (erases username's id)
manage-id set <username> <user-id> (sets usernames id)
manage-id find <string> (list usernames whose id contains <string>)
The above is one way to design the user interface. Here is another:
manage-id --action list
manage-id --action show --username <username>
manage-id --action clear --username <username>
manage-id --action set --username <username> --id <user-id>
manage-id --action find --search <string>
The first is a "positional argument design" and the second a "command-line option design".
I tend to prefer the "command-line option design" for a few reasons:
- the arguments can be presented in any order
- the option names are self-documenting
- removes ambiguity about role of argument (e.g., in the two commands
manage-id show johndoe
andmanage-id find john
, the second argument plays different roles).
On the other hand, the "command-line option design" uses "options" that are not really optional.
My question is this: Is there a recommended (and widely-followed) style choice that prefers one of these two styles over the other for Linux command-line programs?
Best Answer
Your question is a false dichotomy.
Most places I’ve seen use both. Position based parameters for required parameters, and options based parameters for optional parameters. Kinda makes sense, yeah?