我的团队开始使用doxygen记录我们的C代码,特别注意我们的公共API头文件。在doxygen中似乎有很大的灵活性和不同的特殊命令,这很好,但不经过反复试验就不清楚什么是好东西,什么是坏东西。

你最喜欢用什么方法来标记你的代码,你必须做什么和不做什么? 请提供您的最佳建议,每个答案一个,以方便投票。

我希望定义API文档的整个方法,包括提供一个模板让团队的其他成员开始工作。到目前为止,我有这样的东西:

/**
 * @file   example_action.h
 * @Author Me (me@example.com)
 * @date   September, 2008
 * @brief  Brief description of file.
 *
 * Detailed description of file.
 */

/**
 * @name    Example API Actions
 * @brief   Example actions available.
 * @ingroup example
 *
 * This API provides certain actions as an example.
 *
 * @param [in] repeat  Number of times to do nothing.
 *
 * @retval TRUE   Successfully did nothing.
 * @retval FALSE  Oops, did something.
 *
 * Example Usage:
 * @code
 *    example_nada(3); // Do nothing 3 times.
 * @endcode
 */
boolean example(int repeat);

当前回答

如果您发现配置指令INLINE_SOURCES在文档中放置了太多代码,您可以使用\snippet命令手动引用代码的特定部分。

  /**
   * Requirment XYZ is implemented by the following code.
   * 
   * \snippet file.c CODE_LABEL
   */
  int D() 
  {
     //[CODE_LABEL]
     if( A )
     {
        B= C();
     }
     //[CODE_LABEL]
  }

注意:snippet从EXAMPLE_PATH获取文件,而不是源路径。您必须将INPUT指令中的文件和路径列表放在EXAMPLE_PATH指令上。

其他回答

如果你在代码中有bug,或者你发现了bug,你也可以像这样在代码中标记:

/** @bug The text explaining the bug */

当你运行doxygen时,你会得到一个单独的Bug列表和待办事项列表

对于需要5分钟以上生成的大型项目,我发现能够快速为单个文件生成doxygen并在web浏览器中查看它非常有用。

虽然对文件外部任何内容的引用都不会解析,但查看基本格式是否正确仍然是有用的。

这个脚本使用一个文件和项目doxy配置并运行doxygen,我已经将其设置为从我的IDE运行。

#!/usr/bin/env python3
"""
This script takes 2-3 args: [--browse] <Doxyfile> <sourcefile>

  --browse will open the resulting docs in a web browser.
"""
import sys
import os
import subprocess
import tempfile

doxyfile, sourcefile = sys.argv[-2:]

tempfile = tempfile.NamedTemporaryFile(mode='w+b')
doxyfile_tmp = tempfile.name
tempfile.write(open(doxyfile, "r+b").read())
tempfile.write(b'\n\n')
tempfile.write(b'INPUT=' + os.fsencode(sourcefile) + b'\n')
tempfile.flush()

subprocess.call(("doxygen", doxyfile_tmp))
del tempfile

# Maybe handy, but also annoying as default.
if "--browse" in sys.argv:
    import webbrowser
    webbrowser.open("html/files.html")

自动构建和发布您的文档。作为自动构建文档的一部分,注意警告,它很容易写出结构糟糕的注释。

对于复杂的项目,有一个单独的模块管理文件可能很有用,它控制组和子组。整个层次结构可以在一个地方,然后每个文件可以简单地填充到子组中。例如:

/**
 * @defgroup example Top Level Example Group
 * @brief    The Example module.
 *
 * @{
 */

/**
 * @defgroup example_child1 First Child of Example
 * @brief    1st of 2 example children.
 */

/**
 * @defgroup example_child2 Second Child of Example
 * @brief    2nd of 2 example children.
 */

// @}

简单地在另一个组的{}中包含一个组的定义,使其成为该组的子组。然后在代码和头文件中,函数可以被标记为它们所在的任何组的一部分,这一切都可以在完成的文档中工作。它使得重构文档以匹配重构代码更加容易。

一个好的“最佳实践”(虽然并不总是可以实现)是为每个API提供简短的工作示例,并使用\ inclelineno(或\include表示没有行号)将它们拉入帮助。这些可以是单元测试,如果它们的编写是为了让用户能够理解它们(也就是说,没有连接到更大的测试工具中)。作为一个不错的副作用,对API的更改将破坏样本,因此它们必须保持最新。

你可以用文字来描述API,但是没有什么比看到实际的代码来理解如何使用它更好的了。