CS 11: How to write usage statements

If a program is called with incorrect command-line arguments, it should detect that fact and print a usage statement to the terminal. This document tells you what that usage statement should contain, and describes the conventions we expect you to use. It is not exhaustive; there are fairly standard ways to write even more elaborate usage statements than those that are described here, but the information below will at least get you started writing decent usage statements.

Usage statements are essentially the same for all programming languages. The conventions we describe below are for Unix-based operating systems (Linux and Mac OS X); similar conventions exist for Windows but some details may be different.

If you don't know what a command-line argument is, you are not ready to read this document. Go back to your language tutorial, learn what a command-line argument is, come back here and continue reading.

Purpose of a usage statement

A usage statement is a printed summary of how to invoke a program from a shell prompt (i.e. how to write a command line). It will include a description of all the possible command-line arguments that the program might take:

When and where to print a usage statement


A usage statement should always be printed when the user invokes a program with either:

It's important that you explicitly check the number and contents of command-line arguments so as to make sure that they are valid. This process is slightly different for each programming language, so we won't go into it here (see the language tracks for details about this).

To force a program to print its usage message, all you need to do is to type in the program name with no arguments (for programs that take at least one command-line argument). This is a common trick. However, some programs don't have any required command-line arguments (all the arguments are optional; see below). In cases like these, there is usually an optional argument called  -help  which will cause the usage message to be printed. Some programs use  --help  instead of  -help  for this purpose.


The usage message is normally printed to the terminal. In Unix systems, "printing to the terminal" comes in two flavors. Normal printing to the terminal means printing to "standard output" (called stdout in the C language and similar things in other languages). This is not where you should print usage statements. Usage statements should be printed to "standard error" (called stderr in the C language and similar things in other languages). It's important to always print usage statements to stderr and not to stdout.

You might wonder why this is important, given that printing to both stdout and stderr prints to the same terminal window. The reason is that it is possible to redirect either stdout or stderr independently to a file rather than to a terminal. This is very useful in practice. For instance, you might want to log all of your error messages to a log file, but have the normal output go to the terminal as usual. Or you may want to redirect the non-error output to one file, and all the error messages to another file. Having error messages printed to stderr instead of to stdout makes this easy. If all error messages were printed to stdout, the normal output and error messages would not be easy to separate.

What your usage statement should contain

Your usage statement should contain

Formatting guidelines

Optional arguments in usage statements

Many programs have optional command-line arguments. There are various situations in which this can arise:

There are a few conventions you should follow with optional arguments. Here they are:

Other notes