D.3 Tips for Documentation Strings

Here are some tips and conventions for the writing of documentation strings. You can check many of these conventions by running the command M-x checkdoc-minor-mode.

• Every command, function, or variable intended for users to know about should have a documentation string.
• An internal variable or subroutine of a Lisp program might as well have a documentation string. In earlier Emacs versions, you could save space by using a comment instead of a documentation string, but that is no longer the case—documentation strings now take up very little space in a running Emacs.
• The first line of the documentation string should consist of one or two complete sentences that stand on their own as a summary. M-x apropos displays just the first line, and if that line's contents don't stand on their own, the result looks bad. In particular, start the first line with a capital letter and end with a period.

  The documentation string is not limited to one line; use as many lines as you need to explain the details of how to use the function or variable. Please use complete sentences in the additional lines.

• For consistency, phrase the verb in the first sentence of a function's documentation string as an imperative–for instance, use “Return the cons of A and B.” in preference to “Returns the cons of A and B.” Usually it looks good to do likewise for the rest of the first paragraph. Subsequent paragraphs usually look better if each sentence has a proper subject.
• Write documentation strings in the active voice, not the passive, and in the present tense, not the future. For instance, use “Return a list containing A and B.” instead of “A list containing A and B will be returned.”
• Avoid using the word “cause” (or its equivalents) unnecessarily. Instead of, “Cause Emacs to display text in boldface,” write just “Display text in boldface.”
• When a command is meaningful only in a certain mode or situation, do mention that in the documentation string. For example, the documentation of dired-find-file is:

            In Dired, visit the file or directory named on this line.
       

• Do not start or end a documentation string with whitespace.
• Format the documentation string so that it fits in an Emacs window on an 80-column screen. It is a good idea for most lines to be no wider than 60 characters. The first line should not be wider than 67 characters or it will look bad in the output of apropos.

  You can fill the text if that looks good. However, rather than blindly filling the entire documentation string, you can often make it much more readable by choosing certain line breaks with care. Use blank lines between topics if the documentation string is long.

• Do not indent subsequent lines of a documentation string so that the text is lined up in the source code with the text of the first line. This looks nice in the source code, but looks bizarre when users view the documentation. Remember that the indentation before the starting double-quote is not part of the string!
• When the user tries to use a disabled command, Emacs displays just the first paragraph of its documentation string—everything through the first blank line. If you wish, you can choose which information to include before the first blank line so as to make this display useful.
• A variable's documentation string should start with ‘*’ if the variable is one that users would often want to set interactively. If the value is a long list, or a function, or if the variable would be set only in init files, then don't start the documentation string with ‘*’. See Defining Variables.
• The documentation string for a variable that is a yes-or-no flag should start with words such as “Non-nil means...”, to make it clear that all non-nil values are equivalent and indicate explicitly what nil and non-nil mean.
• When a function's documentation string mentions the value of an argument of the function, use the argument name in capital letters as if it were a name for that value. Thus, the documentation string of the function eval refers to its second argument as ‘FORM’, because the actual argument name is form:

            Evaluate FORM and return its value.
       

  Also write metasyntactic variables in capital letters, such as when you show the decomposition of a list or vector into subunits, some of which may vary. ‘KEY’ and ‘VALUE’ in the following example illustrate this practice:

            The argument TABLE should be an alist whose elements
            have the form (KEY . VALUE).  Here, KEY is ...
       

• If a line in a documentation string begins with an open-parenthesis, write a backslash before the open-parenthesis, like this:

            The argument FOO can be either a number
            \(a buffer position) or a string (a file name).
       

  This prevents the open-parenthesis from being treated as the start of a defun (see Defuns).

• When a documentation string refers to a Lisp symbol, write it as it would be printed (which usually means in lower case), with single-quotes around it. For example: ‘lambda’. There are two exceptions: write t and nil without single-quotes. (In this manual, we use a different convention, with single-quotes for all symbols.)

  Help mode automatically creates a hyperlink when a documentation string uses a symbol name inside single quotes, if the symbol has either a function or a variable definition. You do not need to do anything special to make use of this feature. However, when a symbol has both a function definition and a variable definition, and you want to refer to just one of them, you can specify which one by writing one of the words ‘variable’, ‘option’, ‘function’, or ‘command’, immediately before the symbol name. (Case makes no difference in recognizing these indicator words.) For example, if you write

            This function sets the variable `buffer-file-name'.
       

  then the hyperlink will refer only to the variable documentation of buffer-file-name, and not to its function documentation.

  If a symbol has a function definition and/or a variable definition, but those are irrelevant to the use of the symbol that you are documenting, you can write the word ‘symbol’ before the symbol name to prevent making any hyperlink. For example,

            If the argument KIND-OF-RESULT is the symbol `list',
            this function returns a list of all the objects
            that satisfy the criterion.
       

  does not make a hyperlink to the documentation, irrelevant here, of the function list.

  To make a hyperlink to Info documentation, write the name of the Info node in single quotes, preceded by ‘info node’ or ‘Info node’. The Info file name defaults to ‘emacs’. For example,

            See Info node `Font Lock' and Info node `(elisp)Font Lock Basics'.
       

• Don't write key sequences directly in documentation strings. Instead, use the ‘\\[...]’ construct to stand for them. For example, instead of writing ‘C-f’, write the construct ‘\\[forward-char]’. When Emacs displays the documentation string, it substitutes whatever key is currently bound to forward-char. (This is normally ‘C-f’, but it may be some other character if the user has moved key bindings.) See Keys in Documentation.
• In documentation strings for a major mode, you will want to refer to the key bindings of that mode's local map, rather than global ones. Therefore, use the construct ‘\\<...>’ once in the documentation string to specify which key map to use. Do this before the first use of ‘\\[...]’. The text inside the ‘\\<...>’ should be the name of the variable containing the local keymap for the major mode.

  It is not practical to use ‘\\[...]’ very many times, because display of the documentation string will become slow. So use this to describe the most important commands in your major mode, and then use ‘\\{...}’ to display the rest of the mode's keymap.