早上好，下午，晚上或晚上（取决于您的时区）。
这只是关于 C# 中 XML 注释的一般问题。我从来没有非常热衷于评论我的程序，我一直是一个冗长的变量/属性/方法命名器，让代码自己说话。如果我正在编写相当混乱的代码，我会写评论，但在大多数情况下，我不会写很多评论。
我正在阅读 .NET、Sandcastle 中的 XML 注释和 codeplex 上的帮助文件生成器，它让我走上了想要记录我的代码并为那些必须深入研究我的人生成一些很好、有用的文档的道路。当我不再在这里时的代码。
我的问题是关于标准和约定的。是否有“好的”XML 注释指南？你应该评论每一个变量和属性吗？每种方法？我基本上只是在寻找有关如何编写好的注释的提示，这些注释将由 sandcastle 编译成好的文档，这样其他程序员在最终不得不处理我的代码时就不会诅咒我的名字。
提前感谢您的意见和建议，Scott Vercuski
就个人而言，我们确保每个公共和受保护的方法都有 XML 注释。它还将为您提供 Intellisense，而不仅仅是最终用户帮助文档。过去，我们也将它包含在私有范围的声明中，但不认为它是 100% 必需的，只要方法简短且准确即可。
不要忘记有一些工具可以让您更轻松地完成 XML 注释任务：
评论经常过时。这一直是个问题。我的经验法则：更新评论所需的工作越多，评论过时的速度就越快。
XML 注释非常适合 API 开发。它们与 Intellisens 配合得非常好，它们可以让您立即生成 HTML 帮助文档。
但这不是免费的：维护它们会很困难（看看任何重要的例子，你就会明白我的意思），所以它们很快就会过时。因此，审查 XML 注释应作为强制性检查添加到您的代码审查中，并且每次更新文件时都应执行此检查。
好吧，由于维护起来很昂贵，因为许多非私有符号（在非 API 开发中）仅由 1 或 2 个类使用，而且由于这些符号通常是不言自明的，我永远不会强制执行这样的规则每个非私有符号都应该是 XML 注释的。这将是矫枉过正和适得其反。您将得到的是我在很多地方看到的：几乎是空的 XML 注释，对符号名称没有添加任何内容。以及可读性差的代码......
我认为关于普通（非 API）代码中注释的非常非常重要的指导方针不应该是关于它们应该如何编写，而是关于它们应该包含什么。许多开发人员仍然不知道该写什么。对应该注释的内容的描述以及示例对您的代码来说会比简单的：“Do use XML Comments on each non-private symbole.”更好。
我记录了公共类和这些类的公共/受保护成员。
我不记录私人或内部成员或内部类。因此变量（我认为您的意思是字段）因为它们是私有的。
目标是为无法访问源代码的开发人员创建一些文档。
努力举一些用法不明显的例子。
我很少评论方法变量，同样很少评论字段（因为它们通常被属性覆盖，或者如果使用自动实现的属性则根本不存在）。
一般来说，我会努力为所有公共/受保护的成员添加有意义的评论，这很方便，因为如果您在构建期间打开 xml 评论，您会收到缺少评论的自动警告。根据复杂性，我可能不会填写每个细节 - 即，如果每个参数必须做什么是 100% 明显的（即没有特殊的逻辑，并且只有一种解释变量的逻辑方式），那么我可能变得懒惰，不要添加有关参数的注释。
但我当然会尝试描述什么方法、类型、属性等代表/做什么。
我们在我们的库中记录公共方法/属性/等。作为构建过程的一部分，我们使用 NDoc 创建类似 MSDN 的 Web 参考。这对于快速参考和查找非常有帮助。
这对 Intellisense 也非常有用，尤其是对于新团队成员，或者就像你说的，当原作者离开时。
我同意代码通常应该是不言自明的。对我来说，XML 文档更多的是关于在您没有打开源代码时的参考和查找。
我个人的看法是避免评论。评论很危险。因为在行业中我们总是更新代码（因为业务和需求总是在变化），但我们很少更新我们的评论。这可能会误导程序员。