StyleCop和/或通用样式指南？

Question

类似的问题：C#样式指南和StyleCop：一个完整的文档

好的，所以我正在研究一些工作场所应用程序开发的风格控制。我最初只是计划制作一个样式指南（通过收集现有的样式指南并从中选择合适的部分），但似乎StyleCop可能是样式指南的一个很好的补充或替代品。

因此，我的问题是：

1. 使用样式指南和/或StyleCop可能会遇到哪些潜在问题？
2. 如果我使用StyleCop，样式指南需要有多相似？我是否要尝试防止/限制两种方法之间的任何变化？我之所以问这个问题，是因为如果StyleCop没有强制执行，那么它可能会被忽略（或者这不是一个太大的问题吗？）。
3. 如果我正在使用StyleCop，创建样式指南的时间和精力是否值得？
4. 是否有任何值得关注的StyleCop替代品？（例如，具有非常好的可用性/定制性且“可能”被认为足够的替代品）。

编辑：一点背景，我的工作场所有一个“软件部门”，现在只是刚刚形成。有3个全职c#开发人员，3个可能会触摸/使用/更改c#代码的开发人员，若干BA和没有官方测试人员。

- Adrian773

---

我已经编辑了你的标题。请参考“问题的标题应该包含“标签”吗？”，在那里达成共识是“不应该”。 - John Saunders

谢谢，知道了。我最好只是编辑问题，以显示样式指南特别适用于C#。 - Adrian773

Answer 1

我曾经作为一个使用/维护/执行样式指南的团队成员，然后又加入了一个使用StyleCop的团队，我的建议是仅使用StyleCop。原因如下：

1. 它是编译时可执行的。这在处理像样式这样挑剔的东西时是一个巨大的优势。使用样式手册时总有灰色地带，但编译器错误没有。这减少了关于样式的争论从“这是错误的”/“不是”变成了“我们应该选择哪一个”，通常这是一个更文明的争论。

2. 如果你创建自己的风格，那么有人（或所有人）就需要成为人类的“风格警察”，这是一份相当糟糕的工作。开发人员（根据我的经验）倾向于不喜欢别人对他们提交的代码进行“样式调整”，并且更加讨厌被告知使其代码符合样式。这也很耗时，因为在代码审查期间还需要审核这一点（你正在做这些吗？）。

3. StyleCop带有一套相当不错的默认规则，只使用这些规则就可以匹配大多数其他C#代码库。当我使用我们自己的内部样式手册时，所有开源代码都看起来很陌生，因为我们使用注释头、大写参数、一些匈牙利符号等。但是当我转换到StyleCop强制执行的样式并使用默认规则集时，每件事情都变得熟悉了！

4. 创建自己的样式意味着你将花费大量时间重新发明轮子，并在出现边缘情况和争论时维护该轮子。这是一项非零工作量，可能会占用很多时间；根据我的经验，开发人员将永远争论代码样式。

5. 它有一个不错的编辑器来配置您的规则集，如果您不喜欢某些默认值或需要添加缩写，那么StyleCop应该忽略。

你可以编写自己的规则，也可以使用其他人发布的规则。例如，我们团队中的一些人讨厌行尾空格，所以我包含 这些规则 来强制执行。

至于替代方案，我不知道有哪些像 StyleCop 一样无缝集成的工具。需要注意的是，我只在 Resharper / Visual Studio 中使用它，如果你使用其他环境，可能会有所不同。

- Patrick Quirk

---

Visual Studio 2015将作为扩展程序引入即时StyleCop规则执行：https://github.com/DotNetAnalyzers/StyleCopAnalyzers - Sam Harwell

Answer 2

提醒一下，新的StyleCop Analyzers NuGet包在很多方面都有重大改进。现在，您可以通过编辑项目的规则集（属性 -> 代码分析）手动选择StyleCop规则（或者只使用默认选项）。

我刚刚发现，他们甚至为那些追随黑暗面的团队提供了三个“替代”规则... :-)

SX1101 - 不要使用“this.”前缀进行局部调用

SX1309 - 字段名必须以下划线开头

SX1309S - 静态字段名必须以下划线开头

- Riegardt Steyn

Answer 3

你在工作场所能做的最好的事情是教授以下价值观：

1. 识别代码库中已有的样式模式。
2. 遵循在更改该代码库时已有的样式模式。

无论你正在处理什么项目，这种做法都将导致样式问题的退回率最低。同时，在你的样式指南中需要解释的内容也最少。
完成这些后，你可以专注于单个文件无法轻易推断出的主题，例如代码库中使用的命名约定、有效的线程模型以及模块之间的高级交互。

- Sam Harwell