• CLI design: Putting flags to good use

    As the Wikipedia puts it in its Command-line interface page: A command-line option or simply option (also known as a flag or switch) modifies the operation of a command; the effect is determined by the command’s program. Yet, many developers abuse flags to do many unrelated things and therefore end up providing a non-standard and confusing user interface. Let’s take a look at some specific use cases, both bad and good.

  • CLI design: Requesting and offering help

    Any CLI application must offer help to describe its command line syntax: the flags it supports, the subcommands it implements, the meaning of the positional arguments, etc. Failure to do results in an application that is completely unusable: unlike GUI applications, the interface of CLI tools is not discoverable without instructions. It is, therefore, important to realize that help does not only exist to aid the user in recovering from errors.

  • CLI design: Error reporting

    Error reporting is a tricky business. Get it right and your users will be able to correct their actions quickly. Get it wrong and you will be the cause of your user’s frustration — because, face it: A) users will make mistakes and B) your application will encounter erroneous conditions due to bugs or unpredicted scenarios. Understand usage errors and application errors From the programmer’s point of view, there are many types of errors that an application can detect; but, from the point of view of the user, errors can be classified in two broad categories: usage errors and application errors.

  • CLI design: The CLI is the presentation layer

    Treat the code that implements a CLI utility to the highest standards. Let’s step back for a moment. In any graphical application, there always is a chunk of code to deal with the interface of the tool and there is another chunk of code to do the “real work” behind the interface, possibly split into multiple logical layers. This basic split of presentation vs. logic is essential for the maintainability of the code.

  • CLI design: Series introduction

    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.

  • Writing good release notes

    As the developer of a software package, you have just finished preparing a shiny new release. No matter how big the release is, you obviously want your users to upgrade so that they can experience all the new features and bug fixes — or, rather, witness the results of your hard work. But how do you convince them to do so? One of the first things to do is ensure that your release notes are of great quality.

  • Top 5 tips to write great commit log messages

    Writing commit messages is something that every programmer has to face at some point. It may be as early as when starting to contribute to an open source project from home or it can be as late as when joining a job where the development team uses a Version Control System (VCS for short). (Off topic tip: if an open source project or a job you join do not use any VCS, consider twice thrice if you want to do so.