Manual:Coding conventions/Documentation

This is a working draft of a set of conventions for writing documentation. This applies to doc-blocks in code, Markdown files, release notes, and commit messages.

Additions welcome!

Referencing entities
When referring to a concept that exists in code, such as a class, function, or parameter, always reference it exactly like in the code.

Use quotes if it its name starts in lowercase, so to avoid grammatical ambiguity.

Titles and headings
Use sentence case for all headings and page titles.

Describing methods
When documenting a method, the first line should use the imperative mood to describe in one sentence what the method does. Additional text is optional, but if present is separated by a new line.

Describing parameters
When writing a parameter description, start with a capital letter and leave out "a" or "the" at the beginning of the description. Include a period at the end only if the description includes multiple sentences.

One can think of the parameter doc as a table with three columns: "type", "name", and "description". They do not form a continuous sentence, and in visuations the name and description may be rendered separately from each other (e.g. IDE tooltip, JSDoc or Doxygen output).

Text files
Developers can keep documentation files in Git alongside code. These are generally placed in a  directory, or as the   file in a component's subdirectory.

These files are well-suited for detailed documentation about a project's code architecture, database design, etc. These can be updated together with the code in commits that change their behavior. You can link to such Git files on mediawiki.org wiki pages using the  template. For example:.

Further reading & Inspiration

 * WordPress: JavaScript Documentation Standard
 * WordPress: PHP Doc Standard