.net - Stylecop 设置在什么时候不再有用并开始变得烦人？

Question

我在一个团队中工作，我们在 StyleCop 中使用广泛的规则集，我想知道对于这样的工具停止有用并开始变得烦人的一般观点是什么想法。我们还使用 GhostDoc，因此代码中充满了 XML 注释，这使得代码更难阅读和审查。我对 XML 注释没有任何问题，并且发现它们在某些地方非常有用，但是每个字段和属性都真的需要它们吗？

我们有一个令人钦佩的目标，“每个项目在构建时必须有 0 个警告”，但这个目标肯定需要违反合理的 StyleCop 规则集，否则宝贵的时间会浪费在“修复”StyleCop 警告的原因上。

对此有何想法？

编辑
我现在真的想知道像 stylecop 这样的工具的论点是什么？为什么不放弃它，让合理的编码标准和良好的代码审查来处理剩下的事情呢？尤其是在一个优秀的胜任团队中？当然，获得 0 个警告的任务实际上会增加值(value)，因为所有警告都是相关的。

我认为 GhostDoc 的唯一优势是它可以为您从头开始编写 XML 注释节省几秒钟的时间。我认为您不应该在不编辑的情况下接受生成的评论——这可能会适得其反。

这是 GhostDoc 生成的 xml 注释所满足的 Stylecop 规则 (SA1642: ConstructorSummaryDocumentationMustBeginWithStandardText) 的组合 - 是否在一天结束时添加任何值？

    /// <summary>
    /// Initializes a new instance of the <see cref="SomeCustomType"/> class.
    /// </summary>
    /// <param name="someParameter">The someParameter.</param>
    public SomeCustomType(string someParameter)
    {
    }

Answer 1

我认为这更像是一个咆哮而不是一个问题，但我同意你的观点:

过度执行的风格规则是一件坏事。

虽然显然应该有源代码格式的指导方针，但过度规范的牢不可破的规则会导致令人不快的极端情况。在所有情况下都严格遵守规则会产生难以阅读的困惑或过度包装的代码。

编码是一种写作形式，因此奥威尔的奖励规则——“打破任何这些规则，不要说任何完全野蛮的事情”——也需要适用于编码风格指南。

我怀疑自动样式强制执行是一个好主意，在一个可以设置和理解样式指南的称职程序员团队中。自动 lints 对于发现意外错误很有用，但如果应用高度规范的代码格式化法则，它们就无法考虑奥威尔规则。使用强大的规则集，这可能会迫使您以可维护性为幌子编写维护性较差的代码。

如果您的团队中有能力较弱的编码人员，除非被迫进入风格，否则他们的输出是困惑的，那么强制执行可能是一个好主意。 (但是你可能会遇到更大的问题!)

自动评论是一件非常糟糕的事情

我以前没有看过 GhostDoc，但我实际上有点震惊。

他们自己的首页上的例子:

/// <summary>
///     Determines the size of the page buffer.
/// </summary>
/// <param name="initialPageBufferSize">
///     Initial size of the page buffer.
/// </param>
/// <returns></returns>
public int determineBufferSize(int initialPageBufferSize) {

几乎是一个坏评论的典型例子，它对它记录的代码添加了绝对零的洞察力。这绝对比没有评论文档更糟糕。

Javadoc 之后的所有 in-source-doc 模式有时有点令人怀疑，因为它们将源代码与通常针对最终用户的 Material 混在一起 - 与阅读代码的人完全不同的受众。但这绝对是坑。我无法想象谁认为这是个好主意。