Comment by klodolph
6 years ago
I think we should abolish different prefixes for short/long flags except for core POSIX programs (like ls, cp, rm, mkdir, etc.) In other words, "-flag" should be interchangeable with "-flag". The ONLY reason I can think of why you would not recognize "-flag" as equal to "--flag" is because you want to recognize it as "-f -l -a -g", which makes sense for programs like ls, but for 99% of newer programs, don’t do it. Just make "-flag" and "--flag" equivalent.
Strongly disagree. Be consistent, avoid ambiguity, reduce risk of uncertainty. The convention has the feature of combining flags, but there's more. Making -flag and --flag equivalent means combining flags is not possible without potential collisions, and the distinction would become less obvious overall. Usage in practice would be split between -flag and --flag. Enable such inconsistency for what benefits?
Yes, I agree… be consistent and avoid ambiguity. Combined short flags are the most ambiguous of all.
Usage in practice would be split between -flag and --flag… so what? They shouldn’t mean different things, because it is too easy for humans to miss the extra -. And in the end, CLIs are for humans first.
> And in the end, CLIs are for humans first.
I don't think that CLIs are more suited to either humans or computers. CLIs are flexible enough to be effectively used by both.
> Usage in practice would be split between -flag and --flag. So what?
Well, you're breaking everybody's expectations and many years of conventions by doing it. Saving one dash with every flag and losing the ability to combine short options is just not a good trade off.
2 replies →
> for 99% of newer programs, don’t do it
The majority of recent tools in my circle follow this Unix convention. That is a natural result when you use getopt_long().
Right, "don't do it" is imperative mood, not indicative mood. If it were indicative mood, the clause would need a subject but in a casual internet forum I can see why people would omit the subject anyway ¯\_(ツ)_/¯
This is one of the reasons why I don't use getopt_long() -- I don't WANT short flags to be combined, for most commands I write. Fortunately, getopt_long() is one of those library functions that is truly trivial to reimplement and not something that has arcane behavior or edge cases.
Thing is, being able to concatenate options together saves a lot of typing.
(And honestly, —long-flags are rarely useful in practice. Unless you have no man page to figure out what the single letter options do.)
> honestly, —long-flags are rarely useful in practice. Unless you have no man page to figure out what the single letter options do
I agree for the general case: typing commands in a terminal. But I often use long flags in scripts to improve readability.
To increase the readability in scripts, one can use comments. Long options only increase the likelihood of going over someones preferred column count, forcing one to use newline escapes, splitting the command over multiple lines - especially if the command in question is indented. Does that really increase readability? I don't think so personally.
I do the same, along with longer variable names. Every time I went back to look at old code, I am so grateful that I used the more descriptive information.