我无法理解使用XML注释的优点。我知道它们可以转换成代码外部的漂亮文档，但使用更简洁的DOxygen语法可以实现相同的目标。在我看来，XML注释是错误的，因为：
原因可能是什么原因，为什么XML在.NET中更受欢迎而不是简单的DOxygen语法？
答案 0 :(得分：10)
我并不是说DOxygen不是更好，只是xml评论系统对每个人来说都比较熟悉，而且还有很长的路要走。你只需要培训新员工就可以了。
至于将变量取消注释。对你来说可能是显而易见的，不会对其他人（或6个月后的你）。
好的，我想我知道你在问什么。
模糊评论。颜色编码有帮助。就个人而言，我快速扫描灰色文本，只读取绿色，除非我需要阅读xml文本。 （至少在我的设置中）。
我们有大型显示器，所以我们通常会在屏幕上获得更多代码。 （购买大型显示器比购买大型显示器更便宜）。关于这一点的另一件事是，我打赌你一次只是主动查看一个函数，所以如果整个函数适合页面，你可能不会因为没有看到更多代码而遭受太多痛苦。现在，如果函数很长，那么我可以看出这是一个问题。
我们尽可能将摘要评论放在一行（假设它不是很大）。这减少了用过的空间。
我不知道DOxygen是否会这样做，但你可以删除评论，以免它们被挡住。
答案 1 :(得分：7)
XML文档的主要工作是而不是来生成文档。它是为您班级的客户提供良好的IntelliSense信息。将生成的.xml文件与程序集一起发送。
答案 2 :(得分：4)
它们由C＃编译器和Visual Studio本机支持，提供一个位置来记录您的API，以便在打印，在线和智能感知文档中使用。
This article from MSDN magazine声明如下：
在每个项目中，都有人 对文档不满意。 团队领导需要更多评论 技术作家想要的来源 更多关于的书面信息 代码设计，质量保证需要 看功能规格，和 等等。如果所有这些文件都是 实际上写的，你还有 保持所有这些的战斗 同步。
虽然格式不一定理想，但XML文档注释提供了丰富的语法，可以实现这一点。
至于为何选择现有的XML系统而不是DOxygen，我怀疑这主要是因为DOxygen是在GPL下发布的，这意味着Visual Studio和C＃编译器也需要这样发布 - 考虑到terms of the GPL，微软无疑不想这样做。
答案 3 :(得分：3)
我发现更令人讨厌的是ghostdoc插件的受欢迎程度。如果您可以根据方法名称自动生成评论，为什么还要评论？
Steve Yegge说over commenting是新手程序员的标志，我很难与他不同意。答案 4 :(得分：1)
你没有 在你的项目中使用它们。
它们是 标准，恰好集成到Visual Studio中，如果使用StyleCop，则可以强制执行。所以这就是美德。
但是，如果您决定使用DOxygen，那么没有什么可以阻止您。只要确保你是一致的。
答案 5 :(得分：1)
这里没有真正正确的答案。实际上，这两种系统都不比另一种系统“更好” - 它们最终都做同样的工作，这样就可以生成代码文档。
最终输出的格式可以完全相同，并且它们在支持的标签等方面确实具有相同的功能，所以这里真的是个人选择。
就我个人而言，我发现XML注释更具人性化，更符合逻辑，而且简单易用 - 但这样做的另一个好处就是让visual studio自动生成存根，让我只需填写，并提供出色的支持它有折叠他们所以他们不占用屏幕上的大量空间。我确信那些来自VI或some_other_IDE背景编辑的人会有不同的意见，但两者都没有真正的优势。
所以我想说这实际上取决于您使用的IDE以及您和您的团队习惯使用的内容。
现在，如果您问为什么Microsoft选择与Visual Studio中的XML注释紧密集成，那么这是一个不同的问题。很可能是由于以下事实：在VS中实现它们会更简单（因为它们可以重用现有代码来生成/读取注释并构建智能感知等），它们有坚持“标准”的趋势“无论如何（无论是他们自己的还是行业的），以及杰夫提到的许可理由。
只是补充说微软在VS中使用的产品叫做“Sandcastle”，它是一个内部的XML doc生成工具。它有自己的维基页面@ http://docproject.codeplex.com/Wikipage