<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html><head><meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1">
<title>Doxygen manual: Documenting the code</title>
<link href="doxygen.css" rel="stylesheet" type="text/css">
</head><body>
<!-- Generated by Doxygen 1.4.4 -->
<h1><a class="anchor" name="docblocks">Documenting the code</a></h1><h2><a class="anchor" name="specialblock">
Special documentation blocks</a></h2>
A special documentation block is a C or C++ comment block with some additional markings, so doxygen knows it is a piece of documentation that needs to end up in the generated documentation.<p>
For each code item there are two types of descriptions, which together form the documentation: a <em>brief</em> description and <em>detailed</em> description, both are optional. Having more than one brief or detailed description however, is not allowed.<p>
As the name suggest, a brief description is a short one-liner, whereas the detailed description provides longer, more detailed documentation.<p>
There are several ways to mark a comment block as a detailed description: <ol>
<li>
You can use the JavaDoc style, which consist of a C-style comment block starting with two *'s, like this:<p>
<div class="fragment"><pre class="fragment">*
* ... text ...
</pre></div><p>
</li>
<li>
or you can use the Qt style and add an exclamation mark (!) after the opening of a C-style comment block, as shown in this example:<p>
<div class="fragment"><pre class="fragment">!
* ... text ...
</pre></div><p>
In both cases the intermediate *'s are optional, so<p>
<div class="fragment"><pre class="fragment">!
... text ...
</pre></div><p>
is also valid.<p>
</li>
<li>
A third alternative is to use a block of at least two C++ comment lines, where each line starts with an additional slash or an exclamation mark. Here are examples of the two cases:<p>
<div class="fragment"><pre class="fragment">///
/// ... text ...
///
</pre></div><p>
or<p>
<div class="fragment"><pre class="fragment">//!
//!... text ...
//!
</pre></div><p>
</li>
<li>
<p>
Some people like to make their comment blocks more visible in the documentation. For this purpose you can use the following:<p>
<div class="fragment"><pre class="fragment">/////////////////////////////////////////////////
/// ... text ...
/////////////////////////////////////////////////
</pre></div><p>
</li>
</ol>
<p>
For the brief description there are also several posibilities: <ol>
<li>
One could use the <a class="el" href="commands.html#cmdbrief">\brief</a> command with one of the above comment blocks. This command ends at the end of a paragraph, so the detailed description follows after an empty line.<p>
Here is an example:<p>
<div class="fragment"><pre class="fragment">! \brief Brief description.
* Brief description continued.
*
* Detailed description starts here.
</pre></div><p>
</li>
<li>
If <a class="el" href="config.html#cfg_javadoc_autobrief">JAVADOC_AUTOBRIEF</a> is set to <code>YES</code> in the configuration file, then using JavaDoc style comment blocks will automatically start a brief description which ends at the first dot followed by a space or new line. Here is an example:<p>
<div class="fragment"><pre class="fragment">* Brief description which ends at this dot. Details follow
* here.
</pre></div> The option has the same effect for multi-line special C++ comments: <div class="fragment"><pre class="fragment">/// Brief description which ends at this dot. Details follow
/// here.
</pre></div><p>
</li>
<li>
A third option is to use a special C++ style comment which does not span more than one line. Here are two examples: <div class="fragment"><pre class="fragment">/// Brief description.
* Detailed description.
</pre></div><p>
or<p>
<div class="fragment"><pre class="fragment">//! Brief descripion.
//! Detailed description
//! starts here.
</pre></div><p>
Note the blank line in the last example, which is required to separate the brief description from the block containing the detailed description. The <a class="el" href="config.html#cfg_javadoc_autobrief">JAVADOC_AUTOBRIEF</a> should also be set to <code>NO</code> for this case.<p>
</li>
</ol>
<p>
As you can see doxygen is quite flexible. The following however is not legal<p>
<div class="fragment"><pre class="fragment">//! Brief description, which is
//! really a detailed description since it spans multiple lines.
! Oops, another detailed description!
</pre></div><p>
because doxygen only allows one brief and one detailed description.<p>
Furthermore, if there is one brief description before a declaration and one before a definition of a code item, only the one before the <em>declaration</em> will be used. If the same situation occurs for a detailed description, the one before the <em>definition</em> is preferred and the one before the declaration will be ignored.<p>
Here is an example of a documented piece of C++ code using the Qt style: <div class="fragment"><pre class="fragment">//! A test class.
/*!
A more elaborate class description.
*/
class Test
{
public:
//! An enum.
/*! More detailed enum description. */
enum TEnum {
TVal1, /*!< Enum value TVal1. */
TVal2, /*!< Enum value TVal2. */
TVal3 /*!< Enum value TVal3. */
}
//! Enum pointer.
/*! Details. */
*enumPtr,
//! Enum variable.
/*! Details. */
enumVar;
//! A constructor.
/*!
A more elaborate description of the constructor.
*/
Test();
//! A destructor.
/*!
A more elaborate description of the destructor.
*/
~Test();
//! A normal member taking two arguments and returning an integer value.
/*!
\param a an integer argument.
\param s a constant character pointer.
\return The test results
\sa Test(), ~Test(), testMeToo() and publicVar()
*/
int testMe(int a,const char *s);
//! A pure virtual member.
/*!
\sa testMe()
\param c1 the first argument.
\param c2 the second argument.
*/
virtual void testMeToo(char c1,char c2) = 0;
//! A public variable.
/*!
Details.
*/
int publicVar;
//! A function variable.
/*!
Details.
*/
int (*handler)(int a,int b);
};
</pre></div>
Click <a href="../examples/qtstyle/html/class_test.html">here</a>
for the corresponding HTML documentation that is generated by doxygen.
<p>
The one-line comments contain a brief description, whereas the multi-line comment blocks contain a more detailed description.<p>
The brief descriptions are included in the member overview of a class, namespace or file and are printed using a small italic font (this description can be hidden by setting <a class="el" href="config.html#cfg_brief_member_desc">BRIEF_MEMBER_DESC</a> to <code>NO</code> in the config file). By default the brief descriptions become the first sentence of the detailed descriptions (but this can be changed by setting the <a class="el" href="config.html#cfg_repeat_brief">REPEAT_BRIEF</a> tag to <code>NO</code>). Both the brief and the detailed descriptions are optional for the Qt style.<p>
By default a JavaDoc style documentation block behaves the same way as a Qt style documentation block. This is not according the JavaDoc specification however, where the first sentence of the documentation block is automatically treated as a brief description. To enable this behaviour you should set <a class="el" href="config.html#cfg_javadoc_autobrief">JAVADOC_AUTOBRIEF</a> to YES in the configuration file. If you enable this option and want to put a dot in the middle of a sentence without ending it, you should put a backslash and a space after it. Here is an example: <div class="fragment"><pre class="fragment"> * Brief description (e.g.\ using only a few words). Details follow.
</pre></div><p>
Here is the same piece of code as shown above, this time documented using the JavaDoc style and <a class="el" href="config.html#cfg_javadoc_autobrief">JAVADOC_AUTOBRIEF</a> set to YES: <div class="fragment"><pre class="fragment">/**
* A test class. A more elaborate class description.
*/
class Test
{
public:
/**
* An enum.
* More detailed enum description.
*/
enum TEnum {
TVal1, /**< enum value TVal1. */
TVal2, /**< enum value TVal2. */
TVal3 /**< enum value TVal3. */
}
*enumPtr, /**< enum pointer. Details. */
enumVar; /**< enum variable. Details. */
/**
* A constructor.
* A more elaborate description of the constructor.
*/
Test();
/**
* A destructor.
* A more elaborate description of the destructor.
*/
~Test();
/**
* a normal member taking two arguments and returning an integer value.
* @param a an integer argument.
* @param s a constant character pointer.
* @see Test()
* @see ~Test()
* @see testMeToo()
* @see publicVar()
* @return The test results
*/
int testMe(int a,const char *s);
/**
* A pure virtual member.
* @see testMe()
* @param c1 the first argument.
* @param c2 the second argument.
*/
virtual void testMeToo(char c1,char c2) = 0;
/**
* a public variable.
* Details.
*/
int publicVar;
/**
* a function variable.
* Details.
*/
int (*handler)(int a,int b);
};
</pre></div>
Click <a href="../examples/jdstyle/html/class_test.html">here</a>
for the corresponding HTML documentation that is generated by doxygen.
<p>
Unlike most other documentation systems, doxygen also allows you to put the documentation of members (including global functions) in front of the <em>definition</em>. This way the documentation can be placed in the source file instead of the header file. This keeps the header file compact, and allows the implementer of the members more direct access to the documentation. As a compromise the brief description could be placed before the declaration and the detailed description before the member definition.<h2><a class="anchor" name="memberdoc">
Putting documentation after members</a></h2>
If you want to document the members of a file, struct, union, class, or enum, and you want to put the documentation for these members inside the compound, it is sometimes desired to place the documentation block after the member instead of before. For this purpose you should put an additional < marker in the comment block.<p>
Here are some examples: <div class="fragment"><pre class="fragment">int var; !< Detailed description after the member
</pre></div> This block can be used to put a Qt style detailed documentation block <em>after</em> a member. Other ways to do the same are: <div class="fragment"><pre class="fragment">int var; *< Detailed description after the member
</pre></div> or <div class="fragment"><pre class="fragment">int var; //!< Detailed description after the member
//!<
</pre></div> or <div class="fragment"><pre class="fragment">int var; ///< Detailed description after the member
///<
</pre></div><p>
Most often one only wants to put a brief description after a member. This is done as follows: <div class="fragment"><pre class="fragment">int var; //!< Brief description after the member
</pre></div> or <div class="fragment"><pre class="fragment">int var; ///< Brief description after the member
</pre></div><p>
Note that these blocks have the same structure and meaning as the special comment blocks in the previous section only the < indicates that the member is located in front of the block instead of after the block.<p>
Here is an example of the use of these comment blocks: <div class="fragment"><pre class="fragment">/*! A test class */
class Test
{
public:
/** An enum type.
* The documentation block cannot be put after the enum!
*/
enum EnumType
{
int EVal1, /**< enum value 1 */
int EVal2 /**< enum value 2 */
};
void member(); //!< a member function.
protected:
int value; /*!< an integer value */
};
</pre></div>
Click <a href="../examples/afterdoc/html/class_test.html">here</a>
for the corresponding HTML documentation that is generated by doxygen.
<p>
<dl compact><dt><b>Warning:</b></dt><dd>These blocks can only be used to document <em>members</em> and <em>parameters</em>. They cannot be used to document files, classes, unions, structs, groups, namespaces and enums themselves. Furthermore, the structural commands mentioned in the next section (like <code>\class</code>) are ignored inside these comment blocks.</dd></dl>
<h2><a class="anchor" name="structuralcommands">
Documentation at other places</a></h2>
So far we have assumed that the documentation blocks are always located in front of the declaration or definition of a file, class or namespace or in front or after one of its members. Although this is often comfortable, there may sometimes be reasons to put the documentation somewhere else. For documenting a file this is even required since there is no such thing as "in front of a file". Doxygen allows you to put your documentation blocks practically anywhere (the exception is inside the body of a function or inside a normal C style comment block).<p>
The price you pay for not putting the documentation block before (or after) an item is the need to put a structural command inside the documentation block, which leads to some duplication of information.<p>
Structural commands (like all other commands) start with a backslash (<code>\</code>), or an at-sign (<code>@</code>) if you prefer JavaDoc style, followed by a command name and one or more parameters. For instance, if you want to document the class <code>Test</code> in the example above, you could have also put the following documentation block somewhere in the input that is read by doxygen: <div class="fragment"><pre class="fragment">! \class Test
\brief A test class.
A more detailed class description.
</pre></div><p>
Here the special command <code>\class</code> is used to indicate that the comment block contains documentation for the class <code>Test</code>. Other structural commands are: <ul>
<li>
<code>\struct</code> to document a C-struct. </li>
<li>
<code>\union</code> to document a union. </li>
<li>
<code>\enum</code> to document an enumeration type. </li>
<li>
<code>\fn</code> to document a function. </li>
<li>
<code>\var</code> to document a variable or typedef or enum value. </li>
<li>
<code>\def</code> to document a #define. </li>
<li>
<code>\file</code> to document a file. </li>
<li>
<code>\namespace</code> to document a namespace. </li>
<li>
<code>\package</code> to document a Java package. </li>
<li>
<code>\interface</code> to document an IDL interface. </li>
</ul>
See section <a class="el" href="commands.html">Special Commands</a> for detailed information about these and many other commands.<p>
To document a member of a C++ class, you must also document the class itself. The same holds for namespaces. To document a global C function, typedef, enum or preprocessor definition you must first document the file that contains it (usually this will be a header file, because that file contains the information that is exported to other source files).<p>
Let's repeat that, because it is often overlooked: to document global objects (functions, typedefs, enum, macros, etc), you <em>must</em> document the file in which they are defined. In other words, there <em>must</em> at least be a<div class="fragment"><pre class="fragment">! \file </pre></div> or a<div class="fragment"><pre class="fragment">* @file </pre></div> line in this file.<p>
Here is an example of a C header named <code>structcmd.h</code> that is documented using structural commands: <div class="fragment"><pre class="fragment">/*! \file structcmd.h
\brief A Documented file.
Details.
*/
/*! \def MAX(a,b)
\brief A macro that returns the maximum of \a a and \a b.
Details.
*/
/*! \var typedef unsigned int UINT32
\brief A type definition for a .
Details.
*/
/*! \var int errno
\brief Contains the last error code.
\warning Not thread safe!
*/
/*! \fn int open(const char *pathname,int flags)
\brief Opens a file descriptor.
\param pathname The name of the descriptor.
\param flags Opening flags.
*/
/*! \fn int close(int fd)
\brief Closes the file descriptor \a fd.
\param fd The descriptor to close.
*/
/*! \fn size_t write(int fd,const char *buf, size_t count)
\brief Writes \a count bytes from \a buf to the filedescriptor \a fd.
\param fd The descriptor to write to.
\param buf The data buffer to write.
\param count The number of bytes to write.
*/
/*! \fn int read(int fd,char *buf,size_t count)
\brief Read bytes from a file descriptor.
\param fd The descriptor to read from.
\param buf The buffer to read into.
\param count The number of bytes to read.
*/
#define MAX(a,b) (((a)>(b))?(a):(b))
typedef unsigned int UINT32;
int errno;
int open(const char *,int);
int close(int);
size_t write(int,const char *, size_t);
int read(int,char *,size_t);
</pre></div>
Click <a href="../examples/structcmd/html/structcmd_8h.html">here</a>
for the corresponding HTML documentation that is generated by doxygen.
<p>
Because each comment block in the example above contains a structural command, all the comment blocks could be moved to another location or input file (the source file for instance), without affecting the generated documentation. The disadvantage of this approach is that prototypes are duplicated, so all changes have to be made twice! Because of this you should first consider if this is really needed, and avoid structural commands if possible. I often receive examples that contain \fn command in comment blocks which are place in front of a function. This is clearly a case where the \fn command is redundant and will only lead to problems.<p>
Go to the <a href="lists.html">next</a> section or return to the
<a href="index.html">index</a>.
<hr size="1"><address style="align: right;"><small>Generated on Wed Nov 15 11:05:48 2006 for Doxygen manual by
<a href="http://www.doxygen.org/index.html">
<img src="doxygen.png" alt="doxygen" align="middle" border="0"></a> 1.4.4 </small></address>
</body>
</html>
