Ready for a new series?
Having just gone over a bunch of items regarding code readability, it is time to shift gears and get into the topic of the design of Command Line Interfaces (or CLIs for short).
The main focus of this series will be to cover best practices involved in creating applications whose interface is command-line oriented. Among other things, I will detail how the CLI should accept optional and required arguments, how a tool should expose more than one action and how interactive help should be handled.
Please note that console applications that use “drawing” libraries like curses are out of scope in these series: these applications follow to some extent the same principles as GUI-based applications, with the only difference being that their rendering happens in text mode. Therefore, the guidelines for their design are completely different and I don’t have enough experience to comment on them.
And now, a little disclaimer: I am well aware that the articles on this topic can be controversial: there are several different ways to design a CLI just as there are a million ways to design a GUI or a web page. So… just keep in mind that what I will be describing here are my own recollection of thoughts after having had to deal with tons of command line utilities and being annoyed by their inconsistencies and surprising behaviors — all caused by each tool implementing its own style for no real reason.
Hope that you agree, at least, on a few points ;-)
