Linked by David Adams on Fri 5th Aug 2011 17:42 UTC
Graphics, User Interfaces Since we're on a CLI kick today, here's an "attempt at presenting some of the most important guidelines for CLI design."
Permalink for comment 484033
To read all comments associated with this story, please click here.
Comment by abstraction
by abstraction on Mon 8th Aug 2011 01:32 UTC
Member since:

I don't agree with the part that said you should always add long versions of options. The reason beeing that for once it is much more efficient to use a switch case with single characters like 'v' instead of doing a strcmp("verbose" argv[x]). Just look at the difference between the short and the long version of getopts to get the picture.

Also in general although unix programs are seemingly doing one thing and doing it well they do contain a lot of bloat. Just look at all the available options for ls as an example.

There is also the issue of output. Any seasoned user know how to redirect stdout to a file (using > for those who don't). This means there is no need to supply an option with where to output the result of a program. It should always go to stdout by default.

Another issue that this article didn't talk about was programs that you could say acts as wrappers around subfunctions. Take git as an example. You can use git add or git commit or git clone for instance. In this case git acts as a the name for the wrapper and the keyword following is the function it runs. Why this approach was used was probably because different functions requires different options. It is a clever way of grouping together many functions into one program. This you might think is bloated but by clearly defining a subfunction using a keyword that doesn't begin with - it clearly sets the difference between what is the intended function and what is an option. I can accept that. The other option would have been to have many programs called git-add or git-commit which would in most cases require duplication of code.

Edited 2011-08-08 01:37 UTC

Reply Score: 1