尽可能多地使用例子。它自动将API元素链接到示例代码。

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

WARNINGS               = YES
WARN_IF_UNDOCUMENTED   = YES
WARN_IF_DOC_ERROR      = YES

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

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

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

当我发现自己在高分辨率的屏幕上编辑代码时，我已经从使用反斜杠转向使用@前缀的Doxygen命令。不那么嘈杂的反斜杠发现自己现在太难以分辨出Doxygen命令。

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

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

如果您确信您的团队将遵循这样一个重量级模板，那么很好，请按照所示使用它。

否则，它看起来像JavaDoc。Doxygen的优点之一是它不需要使用如此强的标记就能很好地完成工作。你不需要使用@name，通过JAVADOC_AUTOBRIEF设置，你可以跳过@brief——只要确保注释的第一行是一个合理的简短描述。

我更喜欢描述性的名称，而不是强制的文档，并鼓励人们只在增加了重要价值时才添加注释。这样，有价值的评论就不会被所有的噪音淹没。

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

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

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

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