1 /******************************************************************************
5 * Copyright (C) 1997-2015 by Dimitri van Heesch.
7 * Permission to use, copy, modify, and distribute this software and its
8 * documentation under the terms of the GNU General Public License is hereby
9 * granted. No representations are made about the suitability of this software
10 * for any purpose. It is provided "as is" without express or implied warranty.
11 * See the GNU General Public License for more details.
13 * Documents produced by Doxygen are derivative works derived from the
14 * input used in their production; they are not affected by this license.
17 /*! \page docblocks Documenting the code
18 \tableofcontents{html,latex}
20 This chapter covers two topics:
21 1. How to put comments in your code such that doxygen incorporates them in
22 the documentation it generates.
23 This is further detailed in the \ref specialblock "next section".
24 2. Ways to structure the contents of a comment block such that the output
25 looks good, as explained in section \ref docstructure.
27 \section specialblock Special comment blocks
29 A special comment block is a C or C++ style comment block with some
30 additional markings, so doxygen knows it is a piece of structured text that
31 needs to end up in the generated documentation. The \ref cppblock "next" section
32 presents the various styles supported by doxygen.
34 For Python, VHDL, Fortran, and Tcl code there are different commenting
35 conventions, which can be found in sections \ref pythonblocks, \ref vhdlblocks,
36 \ref fortranblocks, and \ref tclblocks respectively.
38 \subsection cppblock Comment blocks for C-like languages (C/C++/C#/Objective-C/PHP/Java)
40 For each entity in the code there are two (or in some cases three) types of descriptions,
41 which together form the documentation for that entity; a *brief* description and *detailed*
42 description, both are optional. For methods and functions there is also a third
43 type of description, the so called *in body* description, which consists of
44 the concatenation of all comment blocks found within the body of the method or function.
46 Having more than one brief or detailed description is allowed (but not recommended,
47 as the order in which the descriptions will appear is not specified).
49 As the name suggest, a brief description is
50 a short one-liner, whereas the detailed description provides longer,
51 more detailed documentation. An "in body" description can also act as a detailed
52 description or can describe a collection of implementation details.
53 For the HTML output brief descriptions are also
54 used to provide tooltips at places where an item is referenced.
56 There are several ways to mark a comment block as a detailed description:
58 <li> You can use the Javadoc style, which consist of a C-style comment
59 block starting with two *'s, like this:
67 <li> or you can use the Qt style and add an exclamation mark (!)
68 after the opening of a C-style comment block, as shown in this example:
76 In both cases the intermediate *'s are optional, so
86 <li> A third alternative is to use a block of <i>at least two</i> C++ comment
87 lines, where each line starts with an additional slash or an
88 exclamation mark. Here are examples of the two cases:
104 Note that a blank line ends a documentation block in this case.
108 Some people like to make their comment blocks more visible in the
109 documentation. For this purpose you can use the following:
112 /********************************************//**
114 ***********************************************/
116 (note the 2 slashes to end the normal comment block and start a special comment block).
121 /////////////////////////////////////////////////
123 /////////////////////////////////////////////////
128 For the brief description there are also several possibilities:
130 <li>One could use the \ref cmdbrief "\\brief" command with one of the
131 above comment blocks. This command ends at the end of a paragraph,
132 so the detailed description follows after an empty line.
137 /*! \brief Brief description.
138 * Brief description continued.
140 * Detailed description starts here.
144 <li>If \ref cfg_javadoc_autobrief "JAVADOC_AUTOBRIEF" is set to \c YES
145 in the configuration file,
146 then using Javadoc style comment
147 blocks will automatically start a brief description which ends at the
148 first dot followed by a space or new line. Here is an example:
151 /** Brief description which ends at this dot. Details follow
155 The option has the same effect for multi-line special C++ comments:
157 /// Brief description which ends at this dot. Details follow
161 <li>A third option is to use a special C++ style comment which does not
162 span more than one line. Here are two examples:
164 /// Brief description.
165 /** Detailed description. */
171 //! Brief description.
173 //! Detailed description
177 Note the blank line in the last example, which is required to separate the
178 brief description from the block containing the detailed description. The
179 \ref cfg_javadoc_autobrief "JAVADOC_AUTOBRIEF" should also be set to \c NO
184 As you can see doxygen is quite flexible. If you have multiple
185 detailed descriptions, like in the following example:
188 //! Brief description, which is
189 //! really a detailed description since it spans multiple lines.
190 /*! Another detailed description!
194 They will be joined. Note that this is also the case if the descriptions
195 are at different places in the code! In this case the order will depend
196 on the order in which doxygen parses the code.
199 Unlike most other documentation systems, doxygen also allows you to put
200 the documentation of members (including global functions) in front of
201 the \e definition. This way the documentation can be placed in the source
202 file instead of the header file. This keeps the header file compact, and allows the
203 implementer of the members more direct access to the documentation.
204 As a compromise the brief description could be placed before the
205 declaration and the detailed description before the member definition.
207 \subsubsection memberdoc Putting documentation after members
209 If you want to document the members of a file, struct, union, class, or enum,
210 it is sometimes desired to place the documentation block after the member
211 instead of before. For this purpose you have to put an additional \< marker
212 in the comment block. Note that this also works for the parameters
215 Here are some examples:
217 int var; /*!< Detailed description after the member */
219 This block can be used to put a Qt style detailed
220 documentation block \e after a member. Other ways to do the
223 int var; /**< Detailed description after the member */
227 int var; //!< Detailed description after the member
232 int var; ///< Detailed description after the member
236 Most often one only wants to put a brief description after a member.
237 This is done as follows:
239 int var; //!< Brief description after the member
243 int var; ///< Brief description after the member
246 For functions one can use the \ref cmdparam "\@param" command to document the parameters
247 and then use <code>[in]</code>, <code>[out]</code>, <code>[in,out]</code>
248 to document the direction. For inline documentation this is also possible
249 by starting with the direction attribute, e.g.
251 void foo(int v /**< [in] docs for input parameter v. */);
254 Note that these blocks have the same structure and meaning as the
255 special comment blocks in the previous section
256 only the \< indicates that the member is
257 located in front of the block instead of after the block.
259 Here is an example of the use of these comment blocks:
262 Click <a href="examples/afterdoc/html/class_afterdoc___test.html">here</a>
263 for the corresponding HTML documentation that is generated by doxygen.
266 See \hyperlink{afterdoc_example}{After Block example}
267 for the corresponding \mbox{\LaTeX} documentation that is generated by doxygen.
270 \warning These blocks can only be used to document \e members and \e parameters.
271 They cannot be used to document files, classes, unions, structs,
272 groups, namespaces and enums themselves. Furthermore, the structural
273 commands mentioned in the next section
274 (like <code>\\class</code>) are not allowed
275 inside these comment blocks.
277 \subsubsection docexamples Examples
279 Here is an example of a documented piece of C++ code using the Qt style:
282 Click <a href="examples/qtstyle/html/class_q_tstyle___test.html">here</a>
283 for the corresponding HTML documentation that is generated by doxygen.
286 See \hyperlink{qtstyle_example}{QT Style example}
287 for the corresponding \mbox{\LaTeX} documentation that is generated by doxygen.
290 The brief descriptions are included in the member overview of a
291 class, namespace or file and are printed using a small italic font
292 (this description can be hidden by setting
293 \ref cfg_brief_member_desc "BRIEF_MEMBER_DESC" to \c NO in
294 the configuration file). By default the brief descriptions become the first
295 sentence of the detailed descriptions
296 (but this can be changed by setting the \ref cfg_repeat_brief "REPEAT_BRIEF"
297 tag to \c NO). Both the brief and the detailed descriptions are optional
300 By default a Javadoc style documentation block behaves the same way as a
301 Qt style documentation block. This is not according the Javadoc specification
302 however, where the first sentence of the documentation block is automatically
303 treated as a brief description. To enable this behavior you should set
304 \ref cfg_javadoc_autobrief "JAVADOC_AUTOBRIEF" to YES in the configuration
305 file. If you enable this option and want to put a dot in the middle of a
306 sentence without ending it, you should put a backslash and a space after it.
309 /** Brief description (e.g.\ using only a few words). Details follow. */
312 Here is the same piece of code as shown above, this time documented using the
313 Javadoc style and \ref cfg_javadoc_autobrief "JAVADOC_AUTOBRIEF" set to YES:
316 Click <a href="examples/jdstyle/html/class_javadoc___test.html">here</a>
317 for the corresponding HTML documentation that is generated by doxygen.
320 See \hyperlink{jdstyle_example}{Javadoc Style example}
321 for the corresponding \mbox{\LaTeX} documentation that is generated by doxygen.
324 Similarly, if one wishes the first sentence of a Qt style documentation
325 block to automatically be treated as a brief description, one may set
326 \ref cfg_qt_autobrief "QT_AUTOBRIEF" to YES in the configuration file.
328 \subsubsection structuralcommands Documentation at other places
330 In the examples in the previous section the comment blocks were always located *in
331 front* of the declaration or definition of a file, class or namespace or *in
332 front* or *after* one of its members.
333 Although this is often comfortable, there may sometimes be reasons to put the
334 documentation somewhere else. For documenting a file this is even
335 required since there is no such thing as "in front of a file".
337 Doxygen allows you to put your documentation blocks practically
338 anywhere (the exception is inside the body of a function or inside a
339 normal C style comment block).
341 The price you pay for not putting the
342 documentation block directly before (or after) an item is the need to put a
343 structural command inside the documentation block, which leads to some
344 duplication of information. So in practice you should \e avoid the use of
345 structural commands \e unless other requirements force you to do so.
347 Structural commands (like \ref cmd_intro "all other commands") start with a backslash
348 (<tt>\\</tt>), or an at-sign (<tt>\@</tt>) if you prefer Javadoc style,
349 followed by a command name and one or more parameters.
350 For instance, if you want to document the class \c Test in the example
351 above, you could have also put the following documentation block somewhere
352 in the input that is read by doxygen:
357 A more detailed class description.
361 Here the special command \c \\class is used to indicate that the
362 comment block contains documentation for the class \c Test.
363 Other structural commands are:
365 <li>\c \\struct to document a C-struct.
366 <li>\c \\union to document a union.
367 <li>\c \\enum to document an enumeration type.
368 <li>\c \\fn to document a function.
369 <li>\c \\var to document a variable or typedef or enum value.
370 <li>\c \\def to document a \#define.
371 <li>\c \\typedef to document a type definition.
372 <li>\c \\file to document a file.
373 <li>\c \\namespace to document a namespace.
374 <li>\c \\package to document a Java package.
375 <li>\c \\interface to document an IDL interface.
377 See section \ref commands for detailed information about these and many other
380 To document a member of a C++ class, you must also document the class
381 itself. The same holds for namespaces. To document a global C function,
382 typedef, enum or preprocessor definition you must first document the file
383 that contains it (usually this will be a header file, because that file
384 contains the information that is exported to other source files).
386 @attention Let's repeat that, because it is often overlooked:
387 to document global objects (functions, typedefs, enum, macros, etc), you
388 <em>must</em> document the file in which they are defined. In other words,
389 there <em>must</em> at least be a \verbatim /*! \file */ \endverbatim
390 or a \verbatim /** @file */ \endverbatim line in this file.
392 Here is an example of a C header named \c structcmd.h that is documented
393 using structural commands:
396 Click <a href="examples/structcmd/html/structcmd_8h.html">here</a>
397 for the corresponding HTML documentation that is generated by doxygen.
400 See \hyperlink{structcmd_example}{Structural Commands example}
401 for the corresponding \mbox{\LaTeX} documentation that is generated by doxygen.
404 Because each comment block in the example above contains a structural command, all
405 the comment blocks could be moved to another location or input file
406 (the source file for instance), without affecting the generated
407 documentation. The disadvantage of this approach is that prototypes are
408 duplicated, so all changes have to be made twice! Because of this you
409 should first consider if this is really needed, and avoid structural
410 commands if possible. I often receive examples that contain \\fn command
411 in comment blocks which are place in front of a function. This is clearly
412 a case where the \\fn command is redundant and will only lead to problems.
414 When you place a comment block in a file with one of the following extensions
415 `.dox`, `.txt`, or `.doc` then doxygen will hide this file from the file list.
417 If you have a file that doxygen cannot parse but still would like to document it,
418 you can show it as-is using \ref cmdverbinclude "\\verbinclude", e.g.
421 /*! \file myscript.sh
422 * Look at this nice script:
423 * \verbinclude myscript.sh
427 Make sure that the script is explicitly listed in the \ref cfg_input "INPUT" or
428 that \ref cfg_file_patterns "FILE_PATTERNS" includes the `.sh` extension and the
429 the script can be found in the path set via \ref cfg_example_path "EXAMPLE_PATH".
431 \subsection pythonblocks Comment blocks in Python
433 For Python there is a standard way of documenting the code using
434 so called documentation strings. Such strings are stored in \c __doc__
435 and can be retrieved at runtime. Doxygen will extract such comments
436 and assume they have to be represented in a preformatted way.
438 \include docstring.py
440 Click <a href="examples/docstring/html/index.html">here</a>
441 for the corresponding HTML documentation that is generated by doxygen.
444 See \hyperlink{python_example}{Python Docstring example}
445 for the corresponding \mbox{\LaTeX} documentation that is generated by doxygen.
448 Note that in this case none of doxygen's \ref cmd_intro "special commands"
451 There is also another way to document Python code using comments that
452 start with "##". These type of comment blocks are more in line with the
453 way documentation blocks work for the other languages supported by doxygen
454 and this also allows the use of special commands.
456 Here is the same example again but now using doxygen style comments:
458 \include pyexample.py
460 Click <a href="examples/pyexample/html/index.html">here</a>
461 for the corresponding HTML documentation that is generated by doxygen.
464 See \hyperlink{py_example}{Python example}
465 for the corresponding \mbox{\LaTeX} documentation that is generated by doxygen.
468 Since python looks more like Java than like C or C++, you should set
469 \ref cfg_optimize_output_java "OPTIMIZE_OUTPUT_JAVA" to \c YES in the
473 \subsection vhdlblocks Comment blocks in VHDL
475 For VHDL a comment normally start with "--". Doxygen will extract comments
476 starting with "--!". There are only two types of comment blocks in VHDL;
477 a one line "--!" comment representing a brief description, and a multi-line
478 "--!" comment (where the "--!" prefix is repeated for each line) representing
479 a detailed description.
481 Comments are always located in front of the item that is being documented
482 with one exception: for ports the comment can also be after the item
483 and is then treated as a brief description for the port.
485 Here is an example VHDL file with doxygen comments:
489 Click <a href="examples/mux/html/index.html">here</a>
490 for the corresponding HTML documentation that is generated by doxygen.
493 See \hyperlink{vhdl_example}{VHDL example}
494 for the corresponding \mbox{\LaTeX} documentation that is generated by doxygen.
497 To get proper looking output you need to set
498 \ref cfg_optimize_output_vhdl "OPTIMIZE_OUTPUT_VHDL" to \c YES in the
499 configuration file. This will also affect a number of other settings. When they
500 were not already set correctly doxygen will produce a warning telling which
501 settings where overruled.
503 \subsection fortranblocks Comment blocks in Fortran
505 When using doxygen for Fortran code you should
506 set \ref cfg_optimize_for_fortran "OPTIMIZE_FOR_FORTRAN" to \c YES.
508 The parser tries to guess if the source code is fixed format Fortran or
509 free format Fortran code. This may not always be correct. If not
510 one should use \ref cfg_extension_mapping "EXTENSION_MAPPING" to correct this.
511 By setting `EXTENSION_MAPPING = f=FortranFixed f90=FortranFree` files with
512 extension \c f are interpreted as fixed format Fortran code and files with
513 extension \c f90 are interpreted as free format Fortran code.
515 For Fortran "!>" or "!<" starts a comment and "!!" or "!>" can be used to
516 continue an one line comment into a multi-line comment.
518 Here is an example of a documented Fortran subroutine:
520 !> Build the restriction matrix for the aggregation
522 !! @param aggr information about the aggregates
523 !! @todo Handle special case
524 subroutine IntRestBuild(A,aggr,Restrict,A_ghost)
526 Type(SpMtx), intent(in) :: A !< our fine level matrix
527 Type(Aggrs), intent(in) :: aggr
528 Type(SpMtx), intent(out) :: Restrict !< Our restriction matrix
533 As an alternative you can also use comments in fixed format code:
537 C> another line of comment
544 \subsection tclblocks Comment blocks in Tcl
546 Doxygen documentation can be included in normal Tcl comments.
548 To start a new documentation block start a line with \c ## (two hashes).
549 All following comment lines and continuation lines will be added to this
550 block. The block ends with a line not starting with a \c # (hash sign).
552 A brief documentation can be added with \c ;#< (semicolon, hash and
553 less-than sign). The brief documentation also ends at a line not starting
554 with a \c # (hash sign).
556 Inside doxygen comment blocks all normal doxygen markings are supported.
557 The only exceptions are described in the following two paragraphs.
559 If a doxygen comment block ends with a line containing only
560 \c #\\code or \c #\@code all code until a line only containing \c #\\endcode
561 or \c #\@endcode is added to the generated documentation as code block.
563 If a doxygen comment block ends with a line containing only
564 \c #\\verbatim or \c #\@verbatim all code until a line only containing
565 \c #\\endverbatim or \c #\@endverbatim is added verbatim to the generated
568 To detect namespaces, classes, functions and variables the following
569 Tcl commands are recognized. Documentation blocks can be put on the lines
573 <li><tt>namespace eval ..</tt> Namespace
574 <li><tt>proc ..</tt> Function
575 <li><tt>variable ..</tt> Variable
576 <li><tt>common ..</tt> Common variable
577 <li><tt>itcl::class ..</tt> Class
578 <li><tt>itcl::body ..</tt> Class method body definition
579 <li><tt>oo::class create ..</tt> Class
580 <li><tt>oo::define ..</tt> OO Class definition
581 <li><tt>method ..</tt> Class method definitions
582 <li><tt>constructor ..</tt> Class constructor
583 <li><tt>destructor ..</tt> Class destructor
584 <li><tt>public ..</tt> Set protection level
585 <li><tt>protected ..</tt> Set protection level
586 <li><tt>private ..</tt> Set protection level
590 To use your own keywords you an map these keyword to the recognized commands
591 using the \ref cfg_tcl_subs "TCL_SUBST" entry in the configuration file.
592 The entry contain a list of word-keyword mappings. To use the itcl::*
593 commands without the leading namespace use p.e.:
595 \verbatim TCL_SUBST = class itcl:class body itcl:body \endverbatim
598 Following is an example using doxygen style comments:
600 \include tclexample.tcl
602 Click <a href="examples/tclexample/html/index.html">here</a>
603 for the corresponding HTML documentation that is generated by doxygen.
606 See \hyperlink{tcl_example}{TCL example}
607 for the corresponding \mbox{\LaTeX} documentation that is generated by doxygen.
611 \section docstructure Anatomy of a comment block
613 The previous section focused on how to make the comments in your code known
614 to doxygen, it explained the difference between a brief and a detailed description, and
615 the use of structural commands.
617 In this section we look at the contents of the comment block itself.
619 Doxygen supports various styles of formatting your comments.
621 The simplest form is to use plain text. This will appear as-is in the output
622 and is ideal for a short description.
624 For longer descriptions you often will find the
625 need for some more structure, like a block of verbatim text, a list, or a
626 simple table. For this doxygen supports the
627 <a href="https://daringfireball.net/projects/markdown/syntax">Markdown</a>
628 syntax, including parts of the
629 <a href="https://michelf.ca/projects/php-markdown/extra/">Markdown Extra</a>
632 Markdown is designed to be very easy to read and write.
633 It's formatting is inspired by plain text mail.
634 Markdown works great for simple, generic formatting, like an introduction
635 page for your project. Doxygen also supports reading of markdown files
636 directly. For more details see chapter \ref markdown.
638 For programming language specific formatting doxygen has two
639 forms of additional markup on top of Markdown formatting.
641 1. <a href="https://en.wikipedia.org/wiki/Javadoc">Javadoc</a> like markup.
642 See \ref commands for a complete overview of all commands supported by doxygen.
643 2. <a href="https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/xmldoc/recommended-tags-for-documentation-comments">XML</a> markup
644 as specified in the <a href="http://standards.iso.org/ittf/PubliclyAvailableStandards/c042926_ISO_IEC_23270_2006(E).zip">C# standard</a>.
645 See \ref xmlcmds for the XML commands supported by doxygen.
647 If this is still not enough doxygen also supports a \ref htmlcmds "subset" of
648 the <a href="https://en.wikipedia.org/wiki/HTML">HTML</a> markup language.
651 Go to the <a href="markdown.html">next</a> section or return to the
652 <a href="index.html">index</a>.