Jay Taylor's notesback to listing index
What are good habits for designing command line arguments?[web search]
While developing the application I started to wonder - How should I design command line arguments?
A lot of programs are using formula like this
My questions are:
Asked for some more details I will provide it. However I think they should not affect the answers. The question is about a good habits in general. I think they are all the same for all kinds of applications.
We are working on an application which will be used in public places (touch totems, tables). Applications are written using Qt Quick 5 (C++, QML, JS). Devices will have Windows 8.1/10 installed. We will provide front-end interface to manage the devices. However some advanced administrators may want to configure the application on their own. It is not very important from the side of the business but as I agree with what Kilian Foth said I do not want my application to be a pain for a user. Not finding in the Internet what I want I asked here.
To more advanced Stack Exchange users: I wanted this question to be general. Maybe it qualifies to the community wiki (I do not know if existing question can be converted with answers). As I want this question to be operating system and programming language independent the answers appearing here can be a valuable lesson for other developers.
On POSIX systems (e.g. Linux, MacOSX), at least for programs possibly started in a shell terminal (e.g. most of them), I would recommend using the GNU coding conventions (which also lists common argument names) and look into the POSIX utilities guidelines, even for proprietary software:
BTW, you might even add some auto-complete facilities for your program and usual shells (like
Some old Unix commands (e.g.
If your software is a series of related command-line programs, take inspiration from git (which you surely use as a development tool), which accepts
In rare cases you might also use
Remember that on POSIX the shell is globbing arguments (before running your program!), so avoid requiring characters (like
In some cases, you could embed an interpreter like GNU guile or Lua in your software (avoid inventing your own Turing-complete scripting language if you are not expert in programming languages). This has deep consequences on the design of your software (so should be thought of early!). You should then easily be able to pass some script or some expression to that interpreter. If you take that interesting approach, design your software and its interpreted primitives with care; you could have some weird user coding big scripts for your thing.
In other cases, you might want to let your advanced users load their plugin into your software (using dynamic loading techniques à la
If your software is a complex thing, make it accept some configuration files (in addition or replacement of program arguments) and probably have some way to test (or just parse) these configuration files without running all the code. For example, a mail transfer agent (like Exim or Postfix) is quite complex, and it is useful to be able to "half-dry" run it (e.g. observing how it is handling some given email address without actually sending an email).
Notice that the
P.S. If possible, make your program a free software, you would get improvements from some users & developers (and adding a new program option is often one of the easiest things to add to an existing free software).
Also, your question depends a lot on the intended audience: a game for teenagers or a browser for grandma probably does not need the same kind and amount of options than a compiler, or a network inspector for datacenter sysadmins, or a CAD software for microprocessor architects or for bridge designers. An engineer familiar with programming & scripting probably likes much more having lots of tunable options than your grandma, and probably might want to be able to run your application without X11 (perhaps in a
The fact that a data format convention is popular is its advantage.
You can easily see that using = or : or even ' ' as a separator are trivial differences that could be converted into each other by computer with little effort. What would be a big effort is for a human to remember "Now see, did this infrequently-used program delimit things with
In other words, for the love of god, don't deviate from extremely entrenched conventions without a compelling reason. People will remember your program as "the one with the weird and annoying cmdline syntax" instead of "the one that saved my college essay".
In layman's terms
When in Rome, do as the Romans do.
I usually do something like this:
One thing that didn't come up yet:
Try to design your software from the command line arguments upwards. Meaning:
Before designing the functionality, design the user interface.
This will allow you to drill down on edge cases and common cases early on. Of course you'll still abstract the outside and the inside, but it's going to give much better result than just writing all the code and then slamming a CLI to it.
Furthermore, check out docopt (http://docopt.org/).
docopt is a great help with that in many languages, especially for python where you have severely limited, user-adverse argument parsers like argparse still being considered as "OK". Instead of having parsers and subparsers and conditional dicts, you just define the syntax help and it does the rest.
Some valuable comments provided already (@Florian, Basile), but let me add ... OP says,
But also remarks:
You must consider your target audience - advanced administrators. What platform do they normally work on - Win/ Unix/ Mac? And what platform does you app run on? Follow whatever CLI conventions have already been established for that platform. Do your "advanced" admins want/ need a GUI based tool?
You want the interface to be consistent internally and with other admin tools. I don't want to stop and think is it
For my Unix admin tools, I have always kept the guidance provided by Heiner's Shelldorado in mind along with the other references mentioned.
As important as designing the CLI is to make sure your application is designed to work with command line arguments the same as from the GUI - ie: no business logic in the GUI or use the common command called from both GUI and CLI.
Most UNIX based administrative tools are actually designed first as command lines tools and the provided GUI simply facilitates "populating" the options for the command line. That approach allows for automation, use of response files, etc. and hands-off management (less work for me!)
As classic toolset used w/this approach is Tcl/Tk. Not suggesting you switch tools; just consider design approach from writing a GUI-based administrative app to the app as a command line tool first; then layer the GUI on top for convenience. At some point you'll likely discover the GUI is a pain (and error prone) if you have to do multiple configs and re-entering generally the same options over and over and you'll look for an automated approach.
Remember your admin likely has to type in the correct values in the correct boxes anyway, so how much effort are you relieving anyway w/GUI ?
protected by gnat Jan 16 at 9:45
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
Not the answer you're looking for? Browse other questions tagged design parameters cli or ask your own question.
10 months ago
Hot Network Questions
- Coworker throwing cigarettes out of a car, I criticized it and now HR is involved
- Giving change in smaller denominations so customers can tip?
- Dealing With Dragonslayers
- How good should one be to participate in Pasporta Servo?
- Start a coup online without the government intervening
- QGIS - When labeling, how can i set different colors based on the value
- Can I pay with cash for the train from Oslo airport to the central station?
- US Election results 2016: What went wrong with prediction models?
- Why is this trigonometric identity true?
- Polyglot Anagrams Cops' Thread
- Find the rate of change at a point on a polynomial
- What is the most someone can lose the popular vote by but still win the electoral college?
- Do we know Ford Prefect's old name?
- Find the "unwrapped size" of a list
- How to stop NPCs from picking up dropped items
- Lab colleague uses cracked software. Should I report it?
- As a monk, can I use Deflect Missiles to protect my ally?
- MathSciNet review alert?
- How can I wrap text around a 2 sided object in Photoshop or Illustrator?
- GO OUT AND VOTE
- How to capture disk usage percentage of a partition as an integer?
- Join lists by observing x-value
- Should I have doubts if the organizers of a workshop ask me to sign a behavior agreement upfront?
- Why is the 'You talking to me' speech from the movie 'Taxi Driver' so famous?
|Technology||Life / Arts||Culture / Recreation||Science||Other|