In my opinion, the following things are usually true:
- Users love long, natural language variations because they are easy to remember.
- Users who write scripts to wrap programs that have hundreds of options love short options.
If the program gets big enough, it eventually ends up short combinations of options that make some sense compared to the canonical option. For example, -Z may be the same as the long variant, which begins with a completely different letter. At this point, especially for one companion, the parsing code becomes a headache to maintain.
You have several options when this happens:
- Use something like gengetopt to write this code for you from a template
- Use only long options (usually a bad idea).
- Try saving your program with up to 52 options (az AZ) (usually a bad idea).
- Implementing options when short parameters become switches that take no arguments, use long parameters for those that do
- A flurry of other methods that make perfect sense for you and make little sense to users.
Mix in different places, and you really begin to grasp the pain.
When I sit down to write a tool that uses a lot of options, the first thing I usually do is write code to parse the arguments, it helps to plan the program flow and becomes an outline. After that, you simply complete each option.
In other words, if you get to the point where options become such a chronic pain, it usually refers to a program that has quickly evolved beyond its planning.
Anyway, to bring my long, pending answer to the end, it is usually best to support atop getopt () behavior whenever possible. The code that receives instructions from the user is simply the cost of doing business, so your concern should be fully about what makes the best user experience possible when possible.
source share