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

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

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

你不需要也不应该在@file指令中写入文件名，doxygen会自动读取文件名。写文件名的问题是，当你重命名文件时，你也必须改变@file指令。

提供@author和@date信息在大多数情况下也是无用的，因为源代码控制系统做得比手动编辑文件要好得多。

如果你使用以下Doxygen语法并在Doxygen的配置中启用JAVADOC_AUTOBRIEF，你也不必写@brief:

/*! Short Description on the first line

    Detailed description...
    ...
*/
void foo(void) {}

函数的@name指令在大多数时候也是100%冗余的，完全无用。它只在有人修改函数名而不是doxygen @name时才会带来错误。

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

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

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

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

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

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

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

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