我的团队开始使用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);

当前回答

不要用@author或@date (@date在另一篇文章中提到过)。这些都是由修订控制系统处理的。

其他回答

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

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

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

总是在类中包含描述。试着说明一个类是如何使用的,或者为什么使用它,而不仅仅是它是什么(通常只是反映了名称)。

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

/**
 * @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.
 */

// @}

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

使用了大量的链接。这可以使用see also链接(如果您喜欢,可以使用\see或@see)来完成,并确保在文档中使用正确的类名引用其他类名。例如,如果你将FUZZYObject类引用为一个“对象”,那么在它后面立即写上类的名称(例如:“疲惫的对象(FUZZYObject)”)。

使用组将代码组织成模块。

请记住,您可以将几乎所有内容放到多个组中,以便它们可以用于提供语义标记,就像Stack Overflow中的标记一样。例如,可以将内容标记为特定于给定平台的内容。

您还可以使用组来匹配IDE中的文件夹层次结构,如我的RB2Doxy示例输出所示。

组在嵌套时工作得很好——我有一个OOFILE源代码的大示例。