---

3.5.1 Writing Documentation Strings

• The command checkdoc-minor-mode

Function: checkdoc-minor-mode &optional arg ¶

Toggle automatic docstring checking (‘Checkdoc’ minor mode).

If called interactively, toggle ‘Checkdoc minor mode’. If the prefix argument is positive, enable the mode, and if it is zero or negative, disable the mode.

If called from Lisp, toggle the mode if ARG is ‘toggle’. Enable the mode if ARG is nil, omitted, or is a positive number. Disable the mode if ARG is a negative number.

The mode’s hook is called both when the mode is enabled and when it is disabled.

• The variable emacs-lisp-docstring-fill-column
  • A documentation string is written using the Lisp syntax for strings, with double-quote characters surrounding the text.
  • 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. Documentation strings take up very little space in a running Emacs.
  • 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. Emacs Lisp mode fills documentation strings to the width specified by emacs-lisp-docstring-fill-column. However, you can sometimes make a documentation string much more readable by adjusting its line breaks with care. Use blank lines between sections if the documentation string is long.

  • 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 it with a period.

    For a function, the first line should briefly answer the question, “What does this function do?” For a variable, the first line should briefly answer the question, “What does this value mean?”

    Don’t limit the documentation string 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 for the rest of the text too.

  • The first line should mention all the important arguments of the function, and should mention them in the order that they are written in a function call. If the function has many arguments, then it is not feasible to mention them all in the first line; in that case, the first line should mention the first few arguments, including the most important arguments.
  • 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 first argument as ‘FORM’, because the actual argument name is form.

    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; e.g. ‘KEY’ and ‘VALUE’.

  • Never change the case of a Lisp symbol when you mention it in a doc string. If the symbol’s name is foo, write “foo”, not “Foo” (which is a different symbol).

    This might appear to contradict the policy of writing function argument values, but there is no real contradiction; the argument value is not the same thing as the symbol that the function uses to hold the value.

    If this puts a lower-case letter at the beginning of a sentence and that annoys you, rewrite the sentence so that the symbol is not at the start of it.

  • Do not start or end a documentation string with whitespace.
  • 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 a documentation string refers to a Lisp symbol, write it as it would be printed (which usually means in lower case), surrounding it with curved single quotes (‘..’). There are two exceptions: write t and nil without surrounding punctuation.

    Documentation strings can also use an older single-quoting convention, which quotes symbols with ‘grave’ accent ‘`’ and ‘apostrophe’ ‘'’: ‘like-this’ rather than ‘like-this’. This older convention was designed for now-obsolete displays in which grave accent and apostrophe were mirror images. Documentation using this convention is converted to the user’s preferred format when it is copied into a help buffer.

    Help mode automatically creates a hyperlink when a documentation string uses a single-quoted symbol name, 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 words ‘symbol’ or ‘program’ 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.

    Normally, no hyperlink is made for a variable without variable documentation. You can force a hyperlink for such variables by preceding them with one of the words ‘variable’ or ‘option’.

    To make a hyperlink to Info documentation, write the single-quoted name of the Info node (or anchor), preceded by ‘info node’, ‘Info node’, ‘info anchor’ or ‘Info anchor’. The Info file name defaults to ‘emacs’. For example,

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

    Finally, to create a hyperlink to URLs, write the single-quoted URL, preceded by ‘URL’. For example,

    The home page for the GNU project has more information (see URL
    `https://www.gnu.org/').
    

  • 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]’.

  • 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.

  • 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 is indicative and has a proper subject.
  • The documentation string for a function that is a yes-or-no predicate should start with words such as “Return t if”, to indicate explicitly what constitutes truth. The word “return” avoids starting the sentence with lower-case “t”, which could be somewhat distracting.
  • 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.”
  • When you define a variable that represents an option users might want to set, use defcustom.
  • 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.

• Text Quoting Style