问题标签 [stylecop]

可能重复：
Usings 应该在命名空间内部还是外部

sa1200 所有 using 指令必须放在命名空间内 (StyleCop)

这只是为了代码可读性还是这样做有什么实际优势？它以某种方式帮助GC吗？

我只是针对我的一些代码运行 style cop 并得到了一些：

现在不要误会我的意思，我喜欢风格警察，当你与一个以上的人一起工作时，这很棒，但这条规则对我来说似乎有点过分。为什么要添加：

到每个变量的顶部。我很确定我记得有人说（Martin Fowler，Kent Beck .. 不记得 ATM）评论应该说“为什么”而不是“什么”，我真的不明白你怎么能解释为什么多变的。

我还发现对每个变量都有注释的代码更难阅读，因为你看到的只是绒毛。

我的想法是，如果您必须解释每个变量是什么，那么您在命名方面确实失败了。

有没有其他人发现注释变量有点代码味道，或者只是我。

我刚刚发现了 sylecop 并在我的项目中运行它，我禁用了某些规则，例如 usings 必须在命名空间内。然而，Visual Studio 自动生成的事件处理程序用于表示单击按钮的形式为 btnOk_Click(....

据我了解，这不符合 stylecop 默认设置，因为它们应该像任何方法一样以大写字母开头。但在代码示例等中，它似乎一直是我的标准。我也习惯了事件处理程序的这种格式，所以有没有办法从这个验证中排除事件处理程序，但让其他方法得到验证？

我正在运行 StyleCop（顺便说一句，如果你想提供高质量的代码，我完全推荐它）......

我有这条线

更新也试过这个

StyleCop 报告错误

如果这是无效的，什么是有效的？

我被要求将 StyleCop 以如下方式集成到我们的 CI 构建过程中：

• 我们（大）解决方案中的单个项目文件不受影响
• 我不必使用任何 3rd 方工具

第一个要求（我还没有完全理解）是因为我们不想直接在整个解决方案上运行 StyleCop。显然，当 StyleCop 在 VS 中运行时，它会忽略某些指定要忽略的文件的属性。正因为如此，如果我们让它在开发机器上运行，我们将不断受到数千个我们尚未准备好处理的违规行为的打击。所以底线是我们希望能够只在构建服务器上运行它。

我们的构建环境目前包括：

巡航控制 > 执行 msbuild 的 nant 任务（通过 exec）

南特任务如下：

当我第一次看到这个时，我认为这将是一个以类似于执行 msbuild 的方式执行 StyleCop 的简单案例。

然而，StyleCop 是作为一组 dll 提供的......

所以这意味着我不能做我想做的事......我想......

我今天用谷歌搜索的所有文章都说“使用 StyleCopCmd”，由于 3rd 方工具限制，我也不能这样做。

我查看了该工具，它似乎实现了一个自定义的 nant 任务，该任务启动 StyleCopConsole，挂钩到几个事件并输出格式良好的报告。但是为了能够证明在内部创建任何工具的合理性，我需要能够充分解释为什么我不能在 nant 配置文件中实现我想要的。或以任何其他不涉及创建或使用工具的方式。理想情况下，如果我不必编写或使用工具，它会更快。

所以我的问题是，这可能吗？

这是特定 StyleCop 配置的问题。

我的 Visual Studio .Net 解决方案文件夹中共有两个 Settings.StyleCop 文件。

第一个放置在文件夹根目录中，其中包含为团队选择的规则。

由于我想禁用特定项目的某些规则，因此我在相应的项目文件夹中放置了另一个 Settings.StyleCop 文件。

结果是：

• 从 Visual Studio IDE（运行 StyleCop）启动分析时，会考虑项目特定文件并且不会发生违规。
• 从 StyleCopCmd（命令工具）启动分析时，项目特定文件似乎被忽略并且发生了一些违规行为。
• 从 MSBuild 目标启动分析时，项目特定文件似乎也被忽略了，并且发生了一些违规行为。

我是否错过了与 StyleCop 配置不同的结果？

我正在使用： Windows XP StyleCop 4.3 MSBuild 3.5 SP1 MSBuild 扩展包 3.5.0.0 StyleCopCmd 0.2.1.0

StyleCop 4.3.1.3 和 MSBuild Extension Pack 3.5.3.0 的问题似乎相同

问候，

奥利维尔。

我想在自定义环境中托管 StyleCop，SDK 中提供的示例代码使用了这个foreach(string myProject in this.myProjects). String没有像Path.GetHashCode()and这样的属性FilesToAnalyze，有谁知道是什么this.myProjects？

我正在使用 StyleCop 和 FxCop 工具来改进我的代码，但我遇到了一个有两条规则的地方，一条在 StyleCop 中，一条在 FxCop 中，它们相互排斥。如果我修复我的代码以匹配来自 StyleCop 的规则，则 FxCop 验证失败，反之亦然。

第一条规则是来自 StyleCop 的 SA1200，它说所有 using 指令都必须放在命名空间内。

所有 using 指令都必须放在命名空间内。

所以我做了这样的事情

StyleCop 没问题，没有更多警告。现在我运行 FxCop 验证，它告诉我违反了 CA1014：

用 CLSCompliant(true) 标记“MyApp.dll”，因为它公开了外部可见的类型。

为了解决这个问题，我应该这样做：

但现在我无法构建我的项目，因为ClsCompliant无法识别属性（因为它来自System我包含在MyNamespace. 因此，如果我将using System; 指令移到MyNamespace声明之外。这将使我的代码编译，但它会再次违反 StyleCop 的规则。

除了禁用 StyleCop 或 FxCop 中的规则之一，还有什么办法可以解决这个问题？如果这不可能，我应该禁用哪些规则？哪个不太重要？

我知道如何做到这一点，但我不知道 StyleCop 方法是否正确/有效。通常在 StyleCop 规则中，您必须将此示例添加到标题中（需要编辑）：

使用 ReSharper 的 StyleCop：

我的最终标题是：

如果我将此标头添加到我的所有来源并共享，我的应用程序会获得 GPL 许可吗？如果不是，问题出在哪里？我希望 StyleCop 方法能奏效。也许我应该将“{one line to give the program's name and a brief idea of​​ what it does.}”移到版权标签的上方。谢谢。

我总是倾向于将所有属于依赖属性（注册、clr 属性、更改回调、强制回调等）的东西分组到一个区域中。但这违反了 stylecop 成员排序规则。这也是生成多个成员的代码片段的普遍问题，因为片段无法在我的文件中的不同位置生成代码。你的哲学是什么？您是取消 stylecop 规则还是将所有内容都放在“正确”的位置？

另外我个人认为 stylcop 不应该抱怨这个：

Stylcop 应该为我们提供额外的工作。在上面的示例中，坚持使用 stylcecop 会使您的工作效率降低，而且代码的可读性也会降低，因为您被迫将上面的代码放在静态 ctor（而不是字段初始化）中，以便能够将 FrameworkPropertyMetadata 转换为临时变量。每个依赖属性的一个额外临时变量不会使代码更具可读性/可维护性，而且您不能再使用代码片段。