在用于构建API文档的注释中，您应该：
解释方法或属性的作用，为什么它存在，并解释任何对代码使用者不自明的领域概念。
列出参数的所有前提条件（不能为空、必须在特定范围内等）。
列出可能会影响调用者处理返回值的后置条件。
列出方法可能抛出的所有异常（以及在什么情况下可能会抛出）。
如果存在类似的方法，请解释它们之间的区别。
注意任何意外情况（例如修改全局状态）。
枚举任何副作用（如果有）。
如果你最终得到的评论没有任何价值，那它们只是浪费而已。
例如：
/// <summary>
/// Gets manager approval for an action
/// </summary>
/// <param name="action">An action object to get approval for</param>
public void GetManagerApprovalFor(Action action)
你没有增加任何价值，只是增加了更多需要维护的代码。
代码中经常充满这些多余的注释。
StyleCop 提供代码和注释风格的提示。它所给出的建议与 MSDN 文档风格一致。
至于注释内容，它应该为您的代码使用者提供足够的信息，以便了解预期的行为类型。它还应该回答可能会产生的问题。因此，请尝试将代码用作不知道任何关于代码的人，或者更好地，请求其他人这样做。
<params>节点时，它会提醒我。根据我上一份工作的经验，R#也可以实时完成这项任务。 - Jesse C. Slicer不要忘记什么是有效的XML。例如：
/// <Summary>
/// Triggers an event if number of users > 1000
/// </Summary>
错误：无效的 XML。
对于属性，您的注释应指示该属性是只读的、写入的还是可读写的。如果查看所有官方的MS文档，属性文档注释总是以"获取..."，"获取或设置..." 开始，而且（很少见，通常避免只写属性）"设置..."
我在写 <summary> 注释时，包括了如果我调用该函数（或实例化该类）时想知道的信息。
我在写 <remarks> 注释时，包括了如果我负责调试或增强该函数或类时想要知道的信息。注意：这并不代替良好的内联注释。但有时候，函数/类内部工作的概述非常有帮助。
如MSDN页面所述，您可以使用XML文档注释自动生成文档，这样如果您正在编写API并且不想在代码和文档上重复工作，同时还可以使它们保持同步 - 每次更改代码时，您都需要修改相应的注释并重新生成文档。
使用/doc进行编译，编译器将搜索源代码中的所有XML标记并创建一个XML文档文件，然后使用Sandcastle等工具生成完整的文档。