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