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

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

// @}

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

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

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

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

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

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

我在代码中使用的一些命令:

为了跟踪待办事项，将在最终文档中创建一个包含待办事项列表的页面。 \c <word>显示使用打字机字体的参数。使用它来引用一个代码字。在你的例子中，我会在“TRUE”和“FALSE”之前使用它。 \a， \警告，\see:详细描述见http://www.stack.nl/~dimitri/doxygen/commands.html#cmdc

如果您有一个非常非常大的项目——大到足以让Doxygen运行一个多小时——您可以将其分割成多个模块，然后Doxygen使用标记文件将其链接在一起。

例如，如果您有一个大的MSVC解决方案，其中包含20个项目，您可以让目录运行自己的Doxygen，然后使用标记文件将输出粘合在一起，就像链接器将.libs粘合在一起以生成可执行文件一样。

您甚至可以更字面地理解链接的比喻，使每个Doxy配置文件对应于一个.vcproj文件，这样每个项目(例如.lib或.dll)都得到自己的Doxy输出。

如果您担心一些团队成员会避免使用文档，或者您只是想要一个最小的文档集，那么您可以在doxygen配置中启用这些。

WARNINGS               = YES
WARN_IF_UNDOCUMENTED   = YES
WARN_IF_DOC_ERROR      = YES

作为doxygen构建过程的一部分，将警告保存到一个文件中，并尝试获得并保持警告计数尽可能低(如果合理则为0)。如果这样做，每个公共和受保护类成员将至少需要一个@brief，每个函数参数的@param和一个@return。这足以描述大多数api，而不会过多妨碍其他活跃的代码库。

当然，您应该鼓励人们在每个案例的基础上尽可能多地记录他们认为需要的文档，只要他们满足最低的项目标准。但是不要将最小值设置得太高，否则最终可能得不到有用的文档。

例如，在我们的项目中，其他程序员可能接触到的所有内容都应该被记录。启用警告，让我们看看我们有多接近这个目标。我们还尝试使用@internal来描述我们对一些私有成员所做的事情。