我在一个团队中工作，我们在StyleCop中使用了广泛的规则集，我想知道关于这样一个工具停止有用并且开始变得烦人的一般观点的想法。我们还使用GhostDoc，因此代码中充斥着XML注释，这使得代码更难以阅读并因此进行审查。我对XML注释没有任何问题，并且发现它们在某些地方非常有用，但它们是否真的需要每个字段和属性？
我们有一个令人钦佩的目标：“每个项目在构建时必须有0个警告”但当然这个目标需要违背合理的StyleCop规则集，否则会浪费宝贵的时间来“修复”StyleCop警告的原因。
对此有何看法？
修改 我现在真的想知道什么是像ALL ALL的stylecop这样的工具？为什么不放弃它，让合理的编码标准和良好的代码审查来处理其余的事情？特别是在一支优秀的团队中？当然，获得0警告的任务实际上会增加价值，因为所有警告都是相关的。
我认为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)
{
}
答案 0 :(得分：24)
我认为这更像是一个咆哮而不是一个问题，但我同意你的看法：
虽然显然应该有源代码格式化指南，但过度规范的不可破坏的规则会导致令人不快的极端情况。在所有情况下严格遵守规则都会产生难以理解的杂乱或过度包装的代码。
编码是各种各样的写作，因此奥威尔的奖金规则 - “打破任何这些规则，而不是说任何直接野蛮的” - 需要也适用于编码风格指南。
我怀疑自动风格执行是一个好主意，在一个能够设置和理解风格指南的能干程序员团队中。自动lint对于捕获意外错误非常有用，但如果采用高度规范性的法律进行代码格式化，则无法考虑Orwell的规则。使用强大的规则集，这可能会迫使您在可维护性的幌子下编写维护较少的代码。
如果你的团队中有一些不太称职的编码员，除非被迫进入风格，他们的输出是混乱的，那么执法可能是一个好主意。 （但那时你可能遇到了更大的问题！）
之前我没见过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模式都有点令人怀疑，因为它们使用通常针对最终用户的材料来混淆源代码 - 与阅读代码的人完全不同。但这是绝对的坑。我无法想象谁认为这是一个好主意。
答案 1 :(得分：14)
StyleCop是工具。它不应该是完美的开箱即用，它不应该满足每个人的需求。
我个人说“是的，这很重要” - 因为当您运行开发团队时，StyleCop会帮助您确保遵守您的编码指南。这正是其目的：以自动化，可测量，一致的方式评估编码标准。如果您不希望能够在构建过程中执行此操作，那么您是对的 - 这是浪费时间。
你自己说：零警告目标“需要反对合理的StyleCop规则集”。运行任何配置不符合您需求的工具都没有意义。如果一条规则对你来说是“烦人的”，那就把它关掉 - 但对于其他人来说这可能是非常重要的。
关于你的“确实增值”问题：是的。人们低估了一致性的价值。如果所有构造函数都具有相同的注释样式，那么如果项目中属性的所有Intellisense具有相同的结构，那么处理它的精神障碍就会减少一个（无论多小）。使用可自动化的工具，几乎不需要付出任何努力。有什么可抱怨的？
答案 2 :(得分：3)
当需要更多时间来编写规则时，可以通过减少维护来获得回报。
如您所知，修复错误需要花费大量时间，而不是编写错误，因此在达到阈值之前，您仍然可以做很多额外的工作来使代码更加健壮和可维护。
答案 3 :(得分：2)
代码编写良好且可读/可维护非常重要，但我们使用Visual Studio和Resharper的代码自动代码格式助手，以及AtomineerUtils以严格定义和整洁的格式保存XML文档注释。
因此，主要的StyleCop规则无关紧要，因为我们的代码始终遵守“默认情况下”的重要规则。较小的StyleCop规则往往对日常使用而言过于严格。 （这些规则中的大多数只对代码的质量或可读性进行了微小的改进，因此我们发现遵守这些规则的成本是不可接受的。我们允许程序员有一点“表达自由” - 只要他们的代码很容易被团队中的其他人阅读，我们不介意编码风格的微小变化）。因此，在评估StyleCop之后，我无法找到任何现实世界的好处。
相比之下，我们发现FXCop非常有用，因为它突出的问题不仅仅是轻微的可读性问题 - 它不时会发现严重的错误和性能问题。
答案 4 :(得分：1)
您的问题中有几点引起了我的注意，所以我想在之前的答案中添加一些想法。
我对XML注释没有任何问题，并且发现它们在某些地方非常有用但是它们是否真的需要在每个字段和属性上？
某些字段和属性对每个人都是如此明显，他们不需要解释。例如，如果某个类Coordinate具有属性X，Y和Z，则评论中无需解释。
但是当谈到像StyleCop这样的工具时，工具无法在明显的属性和有可能难以理解的属性之间产生差异在第一次发现源代码时。所以不，在任何地方都不需要评论，但我们要么对每个字段和属性强制执行注释，要么我们禁用规则并让开发人员决定。
这是由GhostDoc生成的xml注释满足的Stylecop规则（SA1642：ConstructorSummaryDocumentationMustBeginWithStandardText）的组合 - 是否在一天结束时添加任何值？
不知何故。有些工具像其他方法一样显示构造函数，并且您不能在两者之间直观地区分（除非您记住类的名称）。另一方面，XML注释非常清楚，因此很容易理解这是一个构造函数。
顺便问一下，你还会在这里写什么？
还有别的吗？没有构造函数的标准将使得难以阅读代码并理解方法是视图中的构造函数，其中两者以相同的方式显示。
根本没有评论？它可以是一种解决方案，因为可以从类的名称轻松生成此类注释。但它会使事情变得更复杂（为什么自动生成对构造函数的注释而不是其他方法？）。另外，如果您没有提供此构造函数的说明，那么有人怎么知道someParameter是什么？
最后，为了回答你的问题，没有人可以说每个StyleCop规则在每种情况下总是有用的。但请记住这里的废话是“每个项目在构建时必须有0个警告”的目标，而不是StyleCop本身。如果您是一位经验丰富的开发人员并且编写干净的代码，那么没有理由不关闭一些StyleCop规则，至少如果您理解他们的意思，为什么他们在这里以及不遵守规则会产生什么后果。
在我们公司，我们有一个政策，为每个项目使用StyleCop，如果在一个小项目上有数百个警告，那么就有问题。与此同时，我经常遇到一些情况，我在整个课程中禁用了一些StyleCop规则，只是因为它会浪费时间来强制执行它们，并且它不会给任何人带来任何东西。另一方面，当我的同事禁用FxCop / StyleCop 以便能够用法语写出类，方法和属性的名称时，我完全不感激（我在一家法国公司里面也适用于英语口语的开发人员），所以我想说，对于某些人来说，每次都必须启用这两种工具，而无法禁用它们。
答案 5 :(得分：0)
拥有一个每个人都使用的设置样式是有用的，而用于新代码 StyleCop将强制执行此操作以使每个人受益。
但是，当将StyleCop添加到现有项目 以不同风格编写时，您将获得数百，数千或数万次违反基本上是任意规则，例如：
if必须后跟空格this 根据这些规则编辑成千上万行的现有文件只是毫无意义。
如果答案是“关闭StyleCop” - 说实话 - 这样做的方法不止一种。
您的目标应该是消除不代表错误的警告，以便您可以查看 - 然后修复 - 可能会发生的更有问题的警告。有关单行注释格式的1500警告的存在是你无法做到的障碍。
因此，在旧版代码库中