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

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.

Use two spaces between the period marking the end of a sentence and the
word which opens the next sentence. This convention has no effect for
typeset formats like Tex, but improves the readability of the documentation
in fixed-width environments such as the Info reader.

there is no correct for sentence spacing. But we need a convention # good
there is no correct for sentence spacing. But we need a convention # bad

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!

Format the documentation string so that it fits within 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.

When submitting a function to Octave, a tag for the docstring should be added to some appropriate place in one of the manual's .txi source files (they are all in doc/interpreter/). Find the most appropriate section in the manual and add the following with the related functions:

Code: adding tag for function help text in Octave's manual

+@DOCSTRING(function_name)

If appropriate, also write some text about the function on the manual for better inclusion into the manual.

If you give a code example in the documentation written in Texinfo with
the @example environment, you should be aware that the text
within such an environment will not be wrapped. It is recommended that
you keep the lines short enough to fit on pages in the generated pdf or
ps documents. That means, keep the lines of examples under 60 characters.

This environment will enclose the function help text. It takes as argument the type of function. Typical values are

Function File -- for functions in .m files

Loadable Function -- for functions in .oct files

Accessor method

Class property

Besides this environment there is also the alternative deftypenx for alternative forms. Typically these are mentioned at the top of the help text, right after the deftypen although this is not really necessary. Cases where it's acceptable to have them on other sections would be methods on the help text of a class constructor, since they will not always be on a separate file.

Do not use the example environment to insert formulas, consider using @verbatim instead.

@verbatim
E[Z(i,k) ]
IRL(k) = ------------
V(i)
@end verbatim

However, this will never print as a nice looking mathematical formula that TeX is known for. It is possible to have Tex formulas but then they won't be displayed on HTML or Info (Octave help) so the following can be done:

Sometimes it is need to mention matlab in the help text. For example, to mention that a weird behavior needs to be kept for matlab compatibility. In such case, small caps should be used. For example, the following is used in the length help text:

For matrix objects, the length is the number of rows or columns, whichever is
greater (this odd definition is used for compatibility with @sc{matlab}).