flags and usability
6 points by silby
6 points by silby
From a user’s perspective, I have poor memory, and I can’t remember what a single-letter flag means for a program that I don’t use daily. Long command-line arguments are much easier to understand, especially when reading snippets written by others or generated by tools.
Programs can still provide (or even, as this author suggested, constraint themselves to) single-letter arguments. Those are great for interactive use. But please, also provide a long-form alternative.
Some concrete examples would help this argument. I.e. what commands are there that are primarily long-form flagged but are less powerful or harder to use than others with short-form flags?
As a counterexample, tar
uses j
to denote bzip compression, as b
and z
were already used. How intuitive and explorable is that letter compared to the hypothetical --use-compression=bzip
?
The small number of characters available in the alphabet seems to force authors of programmers to think harder about the flags that they are implementing. This results in more usable programs.
I’ve never seen any app constrained by having “only” 52 short options. Even macOS’s ls
has only 44!
The constraint is that the action you are trying to represent with that flag needs to be somewhat understandable or have some connection, such as wc
’s -l
to count lines, because L makes lines. The correlation between the short flag and the action is the limiting factor.
Of course you get other things like tar with the J flag, but the create and extract and verbose and file flags for tar all have reasonable short letters.
It’s a classic trade-off between terse and verbose syntax. All contemporary argument parsing libraries support having both, so use both.
I’m not convinced that the limited alphabet is a net positive for avoiding featuritis. It isn’t guaranteed to help at all, but it always has the cost of a more obscure interface. When adding flags is too hard, tools end up using env variables (less discoverable, harder to control) and more complex combinations of options instead, e.g. ssh
has -o
that escapes the constraint.
The -[a-zA-Z0-9]
argument is pretty thin. First, that’s 62 options, more than any program can add and still claim to “do one thing and do it well”. Also, this is how we got tar
’s infamous usability. On the contrary, long options mean that the users have at least a passing familiarity with the concept of usability outside of the people using the tool every day.
In any case, I like tools with high quality completion scripts. Most tools I use can tab complete after -
or --
and provide short descriptions, and sometimes suggest parameters as well.