docblocks.doc 16.5 KB
Newer Older
dimitri's avatar
dimitri committed
1 2 3 4
/******************************************************************************
 *
 * 
 *
dimitri's avatar
dimitri committed
5
 * Copyright (C) 1997-2008 by Dimitri van Heesch.
dimitri's avatar
dimitri committed
6 7 8 9 10 11 12 13 14 15 16 17 18
 *
 * Permission to use, copy, modify, and distribute this software and its
 * documentation under the terms of the GNU General Public License is hereby 
 * granted. No representations are made about the suitability of this software 
 * for any purpose. It is provided "as is" without express or implied warranty.
 * See the GNU General Public License for more details.
 *
 * Documents produced by Doxygen are derivative works derived from the
 * input used in their production; they are not affected by this license.
 *
 */
/*! \page docblocks Documenting the code

dimitri's avatar
dimitri committed
19
\section specialblock Special documentation blocks
dimitri's avatar
dimitri committed
20

dimitri's avatar
dimitri committed
21
A special documentation block is a C or C++ style comment block with some 
dimitri's avatar
dimitri committed
22
additional markings, so doxygen knows it is a piece of documentation that
dimitri's avatar
dimitri committed
23 24 25
needs to end up in the generated documentation. For Python and VHDL
code there are a different comment conventions, which can be found in section 
\ref pythonblocks and \ref vhdlblocks respectively.
dimitri's avatar
dimitri committed
26

dimitri's avatar
dimitri committed
27 28 29 30 31 32 33 34
For each code item there are two (or in some cases three) types of descriptions, 
which together form the documentation: a \e brief description and \e detailed
description, both are optional. For methods and functions there is also a third
type of description, the so called "in body" description, which consists of 
the concatenation of all comment blocks found within the body of the method or function.

Having more than one brief or detailed description is allowed (but not recommended,
as the order in which the descriptions will appear is not specified).
dimitri's avatar
dimitri committed
35 36 37

As the name suggest, a brief description is
a short one-liner, whereas the detailed description provides longer, 
dimitri's avatar
dimitri committed
38 39 40 41
more detailed documentation. An "in body" description can also act as a detailed
description or can describe a collection of implementation details.
For the HTML output brief descriptions are also
use to provide tooltips at places where an item is referenced.
dimitri's avatar
dimitri committed
42 43 44 45 46 47 48 49 50 51 52 53 54 55 56

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:

\verbatim
/**
 * ... text ...
 */
\endverbatim

<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:

dimitri's avatar
dimitri committed
57 58
\verbatim
/*!
dimitri's avatar
dimitri committed
59 60 61 62 63 64 65 66 67
 * ... text ...
 */
\endverbatim

In both cases the intermediate *'s are optional, so

\verbatim
/*!
 ... text ...
dimitri's avatar
dimitri committed
68
*/
dimitri's avatar
dimitri committed
69 70 71 72
\endverbatim

is also valid.

dimitri's avatar
dimitri committed
73
<li> A third alternative is to use a block of <i>at least two</i> C++ comment 
dimitri's avatar
dimitri committed
74
lines, where each line starts with an additional slash or an 
dimitri's avatar
dimitri committed
75 76 77 78
exclamation mark. Here are examples of the two cases:

\verbatim
///
dimitri's avatar
dimitri committed
79 80
/// ... text ...
///
dimitri's avatar
dimitri committed
81 82 83 84
\endverbatim

or

dimitri's avatar
dimitri committed
85
\verbatim
dimitri's avatar
dimitri committed
86
//!
dimitri's avatar
dimitri committed
87 88
//!... text ...
//!
dimitri's avatar
dimitri committed
89
\endverbatim
dimitri's avatar
dimitri committed
90

dimitri's avatar
dimitri committed
91 92
Note that a blank line ends a documentation block in this case.

dimitri's avatar
dimitri committed
93 94
<li>

dimitri's avatar
dimitri committed
95 96
Some people like to make their comment blocks more visible in the
documentation. For this purpose you can use the following:
dimitri's avatar
dimitri committed
97

dimitri's avatar
dimitri committed
98
\verbatim
dimitri's avatar
dimitri committed
99
/********************************************//**
dimitri's avatar
dimitri committed
100 101 102
 *  ... text
 ***********************************************/
\endverbatim
dimitri's avatar
dimitri committed
103
(note the 2 slashes to end the normal comment block and start a special comment block).
dimitri's avatar
dimitri committed
104 105 106

or

dimitri's avatar
dimitri committed
107
\verbatim
dimitri's avatar
dimitri committed
108 109 110
/////////////////////////////////////////////////
/// ... text ...
/////////////////////////////////////////////////
dimitri's avatar
dimitri committed
111 112 113 114 115 116
\endverbatim

</ol>

For the brief description there are also several posibilities:
<ol>
dimitri's avatar
dimitri committed
117
<li>One could use the \ref cmdbrief "\\brief" command with one of the 
dimitri's avatar
dimitri committed
118 119 120 121 122 123 124 125 126 127
above comment blocks. This command ends at the end of a paragraph, 
so the detailed description follows after an empty line.

Here is an example:

\verbatim
/*! \brief Brief description.
 *         Brief description continued.
 *
 *  Detailed description starts here.
dimitri's avatar
dimitri committed
128
 */
dimitri's avatar
dimitri committed
129 130
\endverbatim

dimitri's avatar
dimitri committed
131 132
<li>If \ref cfg_javadoc_autobrief "JAVADOC_AUTOBRIEF" is set to \c YES 
    in the configuration file, 
dimitri's avatar
dimitri committed
133 134
    then using JavaDoc style comment
    blocks will automatically start a brief description which ends at the
dimitri's avatar
dimitri committed
135
    first dot followed by a space or new line. Here is an example:
dimitri's avatar
dimitri committed
136

dimitri's avatar
dimitri committed
137
\verbatim
dimitri's avatar
dimitri committed
138 139 140
/** Brief description which ends at this dot. Details follow
 *  here.
 */
dimitri's avatar
dimitri committed
141
\endverbatim
dimitri's avatar
dimitri committed
142 143 144 145 146
The option has the same effect for multi-line special C++ comments:
\verbatim
/// Brief description which ends at this dot. Details follow
/// here.
\endverbatim
dimitri's avatar
dimitri committed
147

dimitri's avatar
dimitri committed
148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164
<li>A third option is to use a special C++ style comment which does not 
    span more than one line. Here are two examples:
\verbatim
/// Brief description.
/** Detailed description. */
\endverbatim

or

\verbatim
//! Brief descripion.

//! Detailed description 
//! starts here.
\endverbatim

Note the blank line in the last example, which is required to separate the 
dimitri's avatar
dimitri committed
165 166 167
brief description from the block containing the detailed description. The
\ref cfg_javadoc_autobrief "JAVADOC_AUTOBRIEF" should also be set to \c NO
for this case.
dimitri's avatar
dimitri committed
168 169 170

</ol>

dimitri's avatar
dimitri committed
171 172
As you can see doxygen is quite flexible. If you have multiple
detailed descriptions, like in the following example:
dimitri's avatar
dimitri committed
173 174 175 176

\verbatim
//! Brief description, which is
//! really a detailed description since it spans multiple lines.
dimitri's avatar
dimitri committed
177
/*! Another detailed description!
dimitri's avatar
dimitri committed
178 179 180
 */
\endverbatim

dimitri's avatar
dimitri committed
181 182 183
They will be joined. Note that this is also the case if the descriptions
are at different places in the code! In this case the order will depend
on the order in which doxygen parses the code.
dimitri's avatar
dimitri committed
184 185

Here is an example of a documented piece of C++ code using the Qt style:
dimitri's avatar
dimitri committed
186
\include qtstyle.cpp
dimitri's avatar
dimitri committed
187 188 189 190 191
 \htmlonly
 Click <a href="$(DOXYGEN_DOCDIR)/examples/qtstyle/html/class_test.html">here</a>
 for the corresponding HTML documentation that is generated by doxygen.
 \endhtmlonly

dimitri's avatar
dimitri committed
192
The one-line comments contain a brief description, 
dimitri's avatar
dimitri committed
193
whereas the multi-line comment blocks contain a more detailed description.
dimitri's avatar
dimitri committed
194 195

The brief descriptions are included in the member overview of a 
dimitri's avatar
dimitri committed
196 197 198 199 200 201 202
class, namespace or file and are printed using a small italic font 
(this description can be hidden by setting 
\ref cfg_brief_member_desc "BRIEF_MEMBER_DESC" to \c NO 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 \ref cfg_repeat_brief "REPEAT_BRIEF" 
tag to \c NO). Both the brief and the detailed descriptions are optional 
dimitri's avatar
dimitri committed
203 204
for the Qt style. 

dimitri's avatar
dimitri committed
205 206 207 208 209
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
\ref cfg_javadoc_autobrief "JAVADOC_AUTOBRIEF" to YES in the configuration
dimitri's avatar
dimitri committed
210
file. If you enable this option and want to put a dot in the middle of a
dimitri's avatar
dimitri committed
211 212 213 214 215 216 217 218
sentence without ending it, you should put a backslash and a space after it.
Here is an example:
\verbatim
  /** Brief description (e.g.\ using only a few words). Details follow. */
\endverbatim

Here is the same piece of code as shown above, this time documented using the 
JavaDoc style and \ref cfg_javadoc_autobrief "JAVADOC_AUTOBRIEF" set to YES:
dimitri's avatar
dimitri committed
219
\include jdstyle.cpp
dimitri's avatar
dimitri committed
220 221 222 223 224
 \htmlonly
 Click <a href="$(DOXYGEN_DOCDIR)/examples/jdstyle/html/class_test.html">here</a>
 for the corresponding HTML documentation that is generated by doxygen.
 \endhtmlonly

dimitri's avatar
dimitri committed
225 226 227 228
Similarly, if one wishes the first sentence of a Qt style documentation
block to automatically be treated as a brief description, one may set
\ref cfg_qt_autobrief "QT_AUTOBRIEF" to YES in the configuration file.

dimitri's avatar
dimitri committed
229 230 231 232 233 234
Unlike most other documentation systems, doxygen also allows you to put
the documentation of members (including global functions) in front of 
the \e definition. 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
dimitri's avatar
dimitri committed
235
declaration and the detailed description before the member definition.
dimitri's avatar
dimitri committed
236

dimitri's avatar
dimitri committed
237
\section memberdoc Putting documentation after members 
dimitri's avatar
dimitri committed
238 239 240 241

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 
dimitri's avatar
dimitri committed
242
instead of before. For this purpose you have to put an additional \< marker
dimitri's avatar
dimitri committed
243 244
in the comment block. Note that this also works for the parameters 
of a function.
dimitri's avatar
dimitri committed
245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276

Here are some examples:
\verbatim
int var; /*!< Detailed description after the member */
\endverbatim
This block can be used to put a Qt style detailed 
documentation block \e after a member. Other ways to do the
same are:
\verbatim
int var; /**< Detailed description after the member */
\endverbatim
or 
\verbatim
int var; //!< Detailed description after the member
         //!< 
\endverbatim
or 
\verbatim
int var; ///< Detailed description after the member
         ///< 
\endverbatim

Most often one only wants to put a brief description after a member.
This is done as follows:
\verbatim
int var; //!< Brief description after the member
\endverbatim
or
\verbatim
int var; ///< Brief description after the member
\endverbatim

dimitri's avatar
dimitri committed
277 278 279 280 281 282 283 284
For functions one can use \@param to document the parameters
and then use <code>[in]</code>, <code>[out]</code>, <code>[in,out]</code> 
to document the direction. For inline documentation this is also possible 
by starting with the direction attribute, e.g.
\verbatim
void foo(int v /**< [in] docs for input parameter v. */);
\endverbatim

dimitri's avatar
dimitri committed
285 286 287 288 289 290
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.

Here is an example of the use of these comment blocks:
dimitri's avatar
dimitri committed
291
\include afterdoc.h
dimitri's avatar
dimitri committed
292 293 294 295 296 297 298 299 300
 \htmlonly
 Click <a href="$(DOXYGEN_DOCDIR)/examples/afterdoc/html/class_test.html">here</a>
 for the corresponding HTML documentation that is generated by doxygen.
 \endhtmlonly

\warning These blocks can only be used to document \e members and \e parameters.
         They cannot be used to document files, classes, unions, structs,
         groups, namespaces and enums themselves. Furthermore, the structural 
         commands mentioned in the next section 
dimitri's avatar
dimitri committed
301 302
         (like <code>\\class</code>) are not allowed 
         inside these comment blocks.
dimitri's avatar
dimitri committed
303

dimitri's avatar
dimitri committed
304
\section structuralcommands Documentation at other places
dimitri's avatar
dimitri committed
305

dimitri's avatar
dimitri committed
306 307
So far we have assumed that the documentation blocks are always located \e in 
\e front of the declaration or definition of a file, class or namespace or in
dimitri's avatar
dimitri committed
308 309 310 311
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". 
dimitri's avatar
dimitri committed
312

dimitri's avatar
dimitri committed
313 314 315 316 317
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). 

The price you pay for not putting the
dimitri's avatar
dimitri committed
318
documentation block directly before (or after) an item is the need to put a  
dimitri's avatar
dimitri committed
319
structural command inside the documentation block, which leads to some
dimitri's avatar
dimitri committed
320 321
duplication of information. So in practice you should \e avoid the use of
structural commands \e unless other requirements force you to do so.
dimitri's avatar
dimitri committed
322 323

Structural commands (like all other commands) start with a backslash 
dimitri's avatar
dimitri committed
324
(<tt>\\</tt>), or an at-sign (<tt>\@</tt>) if you prefer JavaDoc style, 
dimitri's avatar
dimitri committed
325
followed by a command name and one or more parameters.
dimitri's avatar
dimitri committed
326 327 328 329 330 331 332 333 334 335 336
For instance, if you want to document the class \c Test in the example
above, you could have also put the following documentation block somewhere
in the input that is read by doxygen:
\verbatim
/*! \class Test
    \brief A test class.

    A more detailed class description.
*/
\endverbatim

dimitri's avatar
dimitri committed
337
Here the special command \c \\class is used to indicate that the
dimitri's avatar
dimitri committed
338 339 340
comment block contains documentation for the class \c Test.
Other structural commands are:
<ul>
dimitri's avatar
dimitri committed
341 342 343 344 345 346
<li>\c \\struct to document a C-struct.
<li>\c \\union to document a union.
<li>\c \\enum to document an enumeration type.
<li>\c \\fn to document a function.
<li>\c \\var to document a variable or typedef or enum value.
<li>\c \\def to document a \#define.
dimitri's avatar
dimitri committed
347
<li>\c \\typedef to document a type definition.
dimitri's avatar
dimitri committed
348 349 350 351
<li>\c \\file to document a file.
<li>\c \\namespace to document a namespace.
<li>\c \\package to document a Java package.
<li>\c \\interface to document an IDL interface.
dimitri's avatar
dimitri committed
352
</ul>
dimitri's avatar
dimitri committed
353 354
See section \ref commands for detailed information about these and many other 
commands. 
dimitri's avatar
dimitri committed
355 356

To document a member of a C++ class, you must also document the class 
dimitri's avatar
dimitri committed
357 358 359 360
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).
dimitri's avatar
dimitri committed
361

dimitri's avatar
dimitri committed
362 363 364 365 366 367
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 \verbatim /*! \file */ \endverbatim
or a \verbatim /** @file */ \endverbatim line in this file.

dimitri's avatar
dimitri committed
368 369
Here is an example of a C header named \c structcmd.h that is documented 
using structural commands:
dimitri's avatar
dimitri committed
370
\include structcmd.h
dimitri's avatar
dimitri committed
371
 \htmlonly
dimitri's avatar
dimitri committed
372
 Click <a href="$(DOXYGEN_DOCDIR)/examples/structcmd/html/structcmd_8h.html">here</a>
dimitri's avatar
dimitri committed
373 374 375
 for the corresponding HTML documentation that is generated by doxygen.
 \endhtmlonly

dimitri's avatar
dimitri committed
376 377 378 379 380 381 382 383 384
 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.
dimitri's avatar
dimitri committed
385

dimitri's avatar
dimitri committed
386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403
\section pythonblocks Special documentation blocks in Python

For Python there is a standard way of documenting the code using 
so called documentation strings. Such strings are stored in \c __doc__
and can be retrieved at runtime. Doxygen will extract such comments
and assume they have to be represented in a preformatted way.

\include docstring.py
 \htmlonly
 Click <a href="$(DOXYGEN_DOCDIR)/examples/docstring/html/index.html">here</a>
 for the corresponding HTML documentation that is generated by doxygen.
 \endhtmlonly

Note that in this case none of doxygen's \ref cmd_intro "special commands" 
are supported.

There is also another way to document Python code using comments that 
start with "##". These type of comment blocks are more in line with the 
dimitri's avatar
dimitri committed
404
way documentation blocks work for the other languages supported by doxygen 
dimitri's avatar
dimitri committed
405 406 407 408 409 410 411 412 413 414 415 416 417 418 419
and this also allows the use of special commands. 

Here is the same example again but now using doxygen style comments:

\include pyexample.py
 \htmlonly
 Click <a href="$(DOXYGEN_DOCDIR)/examples/pyexample/html/index.html">here</a>
 for the corresponding HTML documentation that is generated by doxygen.
 \endhtmlonly

Since python looks more like Java than like C or C++, you should set 
\ref cfg_optimize_output_java "OPTMIZE_OUTPUT_JAVA" to \c YES in the
config file. 


dimitri's avatar
dimitri committed
420
\htmlonly
dimitri's avatar
dimitri committed
421
Go to the <a href="lists.html">next</a> section or return to the
dimitri's avatar
dimitri committed
422 423 424
 <a href="index.html">index</a>.
\endhtmlonly

dimitri's avatar
dimitri committed
425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450
\section vhdlblocks Special documentation blocks in VHDL

For VHDL a comment normally start with "--". Doxygen will extract comments
starting with "--!". There are only two types of comment blocks in VHDL;
a one line --! comment representing a brief description, and a multiline
--! comment (where the --! prefix is repeated for each line) representing
a detailed description.

Comments are always located in front of the item that is being documented
with one exception: for ports the comment can also be after the item
and is then treated as a brief description for the port.

Here is an example VHDL file with doxygen comments:

\include  mux.vhdl
 \htmlonly
 Click <a href="$(DOXYGEN_DOCDIR)/examples/mux/html/index.html">here</a>
 for the corresponding HTML documentation that is generated by doxygen.
 \endhtmlonly

To get proper looking output you need to set
\ref cfg_optimize_output_vhdl "OPTIMIZE_OUTPUT_VHDL" to \c YES in the
config file. This will also affect a number of other settings. When they
were not already set correctly doxygen will produce a warning telling which
settings where overruled.

dimitri's avatar
dimitri committed
451
*/