C++ Documentation Style

This page is part of the Qt Writing Guidelines.

Though there are exceptions, these guidelines should be followed. Keeping that in mind, at least be consistent within the page. Meaning, the class member documentation should have the same style.

To generate the documentation, QDoc goes through the source code and generates documentation for C++ types such as classes. QDoc then associates member functions, properties, and other types to the appropriate class.

Note that the documentation must be in the implementation files such as .cpp files.

Class Documentation

Class documentation is generated using the \class [doc-snapshot.qt-project.org] command and the name of the class as the first argument.

  1. /*!
  2.     \class QCache
  3.     \brief A template class that provides a cache.
  4.     \inmodule QtCore
  5.     \ingroup tools
  6.     \ingroup shared
  7.  
  8.     \reentrant
  9.  
  10.     QCache\<Key, T\> defines a cache that stores objects of type T
  11.     associated with keys of type Key. For example, here's the
  12.     definition of a cache that stores objects of type Employee
  13.     associated with an integer key:
  14.  
  15.     \snippet code/doc_src_qcache.cpp 0
  16.  
  17.     Here's how to insert an object in the cache:
  18.  
  19.     \snippet code/doc_src_qcache.cpp 1
  20.  
  21.     ... detailed description omitted
  22.  
  23.     \sa QPixmapCache, QHash, QMap
  24. */

Context commands [doc-snapshot.qt-project.org] add information about the class, such as its module or
which version the class was added.

Some required context commands are:

  • \brief [doc-snapshot.qt-project.org] – the class’ brief description. mandatory
  • \since [doc-snapshot.qt-project.org] – the version to which the class was added . mandatory (see Note section about backdating APIs)
  • \inmodule [doc-snapshot.qt-project.org] – associates a class to a Qt module. mandatory
  • \internal [doc-snapshot.qt-project.org] – marks the class as internal. Internal classes do not appear in the public API documentation.

Note: It was decided that we will not backdate APIs, so only add the \since with the version number of an upcoming release. See https://codereview.qt-project.org/#change,43797

The Brief and Detailed Description

The brief description is marked with the \brief [doc-snapshot.qt-project.org] command and it is for summarizing the purpose or functionality of the class. QDoc adds the brief descriptions to the annotated lists and tables listing the C++ classes. It is a good practice to begin a brief description with a verb.

The Detailed Description section starts after the brief description. It provides more information about the class. The detailed description may contain images, snippet code, or links to other relevant documents. There must be an empty line which separates the brief and detailed description.

Member Functions

Typically, function documentation immediately precedes the implementation of the function in the .cpp file. For function documentation that is not immediately above the implementation, the \fn [doc-snapshot.qt-project.org] is needed.

  1. /*!
  2.   \fn QString &QString::remove(int position, int n)
  3.  
  4.   Removes \a n characters from the string, starting at the given \a
  5.   position index, and returns a reference to the string.
  6.  
  7.   If the specified \a position index is within the string, but \a
  8.   position + \a n is beyond the end of the string, the string is
  9.   truncated at the specified \a position.
  10.  
  11.   \snippet qstring/main.cpp 37
  12.  
  13.   \sa insert(), replace()
  14. */

The function documentation starts with a verb, indicating the operation the function performs. This also applies to constructors and destructors.

Some common verbs for function documentation:

  • “Constructs…” – for constructors
  • “Destroys…” – for destructors
  • “Returns…” – for accessor functions

The function documentation must document:

  • the return type
  • the parameters
  • the actions of the functions

The \a [doc-snapshot.qt-project.org] command marks the parameter in the documentation.
The return type documentation should link to the type documentation or be marked with the \c [doc-snapshot.qt-project.org] command in the case of boolean values.

  1. /*!
  2.     Returns \c true if a QScroller object was already created for \a target; \c false otherwise.
  3.  
  4.     \sa scroller()
  5. */

Properties

The property documentation resides immediately above the read function’s implementation. The topic-commands [doc-snapshot.qt-project.org] for properties is \property [doc-snapshot.qt-project.org].

  1. /*!
  2.     \property QVariantAnimation::duration
  3.     \brief the duration of the animation
  4.  
  5.     This property describes the duration in milliseconds of the
  6.     animation. The default duration is 250 milliseconds.
  7.  
  8.     \sa QAbstractAnimation::duration()
  9. */

Property documentation usually starts with “This property…”, but these are alternate expressions:

  • “This property holds…”
  • “This property describes…”
  • “This property represents…”
  • “Returns \c true when… and \c false when…” – for properties that are read.
  • “Sets the…” – for properties that configure a type.

Property documentation must include:

  • description and behavior of the property
  • accepted values for the property
  • the default value of the property
    Similar to functions, the default type may be linked or marked with the \c command.

An example of a value range style is:

  1. The values range from \c 0.0 (no blur) to maximumRadius (maximum blur). By default, the property is set to \c 0.0 (no blur).

Signals, Notifiers, and Slots

The topic command [doc-snapshot.qt-project.org] for signals, notifiers, and slots
is \fn [doc-snapshot.qt-project.org]. Signal documentation state when they are triggered or emitted.

  1. /*!
  2.   \fn QAbstractTransition::triggered()
  3.  
  4.   This signal is emitted when the transition has been triggered (after
  5.   onTransition() has been called).
  6. */

Signal documentation typically begin with “This signal is triggered when…”. Here are alternate styles:

  • “This signal is triggered when…”
  • “Triggered when…”
  • “Emitted when…”

For slots or notifiers, the condition when they are executed or triggered by a signal should be documented.

  • “Executed when…”
  • “This slot is executed when…”

For properties that have overloaded signals, QDoc groups the overloaded notifiers together. To refer to a specifc version of a notifier or signal, simply refer to the property and mention that there are different versions of the notifier.

  1. /*!
  2.     \property QSpinBox::value
  3.     \brief the value of the spin box
  4.  
  5.     setValue() will emit valueChanged() if the new value is different
  6.     from the old one. The \l{QSpinBox::}{value} property has a second notifier
  7.     signal which includes the spin box's prefix and suffix.
  8. */

Enums, Namespaces, and other Types

Enums, namespaces, and macros have a topic-command [doc-snapshot.qt-project.org] for their documentation:

  • \enum [doc-snapshot.qt-project.org]
  • \typedef [doc-snapshot.qt-project.org]
  • \macro [doc-snapshot.qt-project.org]

The language style for these types mention that they are an enum or a macro and
continues with the type description.

For enumerations, the \value [doc-snapshot.qt-project.org] command is used to list the values. QDoc creates a table containing the enum values.

  1. /*!
  2.     \enum QSql::TableType
  3.  
  4.     This enum type describes types of SQL tables.
  5.  
  6.     \value Tables  All the tables visible to the user.
  7.     \value SystemTables  Internal tables used by the database.
  8.     \value Views  All the views visible to the user.
  9.     \value AllTables  All of the above.
  10. */