Positional arguments vs options in a command-line interface

coding-standardscommand lineuser interface

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 and manage-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?

Related Topic