Tips for Documentation Strings

Here are some tips for the writing of documentation strings.

• Every command function, or variable intended for users to know about should have a documentation string.
• An internal variable or subroutine of an Octave program might as well have a documentation string.
• The first line of the documentation string should consist of one or two complete sentences that stand on their own as a summary.

  The documentation string can have additional lines that expand on the details of how to use the function or variable. The additional lines should also be made up of complete sentences.

• For consistency phrase the verb in the first sentence of a documentation string as an infinitive with "to" omitted. For instance use "Return the frob of A and B." in preference to "Returns the frob of A and B." Usually it looks good to do likewise for the rest of the first paragraph. Subsequent paragraphs usually look better if they have proper subjects.
• 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 Octave to display text in boldface," write just "Display text in boldface."
• 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.

  However rather than simply filling the entire documentation string, you can make it much more readable by choosing 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!
• The documentation string for a variable that is a yes-or-no flag should start with words such as "Nonzero means..." to make it clear that all nonzero values are equivalent and indicate explicitly what zero and nonzero 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 operator / refers to its second argument as DIVISOR because the actual argument name is divisor.

  Also use all caps for meta-syntactic variables such as when you show the decomposition of a list or vector into subunits some of which may vary.