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

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

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

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

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

为了跟踪待办事项，将在最终文档中创建一个包含待办事项列表的页面。 \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输出。

如果您发现配置指令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指令上。

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

WARNINGS               = YES
WARN_IF_UNDOCUMENTED   = YES
WARN_IF_DOC_ERROR      = YES

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

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

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