您要停用 FxCop 的哪条规则？
我个人还没有使用 FxCop。 我们希望在进行代码分析之前先完成单元测试。 但是，您会永久停用哪些规则？ 在什么情况下您会暂时停用哪些规则？
I personally don't use FxCop yet. We want to work out the unit testing first before going with code analysis. However, which rules would you permanantly deactivate? Which rules would you deactivate temporarily and in which situation?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我不喜欢规则 CA1021：避免使用 out 参数。 输出参数对于许多不同的模式都很有用（包括 .Net Try* 模式）。 Out 当然可能会被过度使用，但实际上为其制定 FxCop 规则似乎有些过分了。
规则 CA1021
I dislike rule CA1021: Avoid out parameters. Out parameters are useful for many different patterns (including the .Net Try* pattern). Out can certainly be overused but really it seems overkill to have an FxCop rule for it.
Rule CA1021
CA2210 程序集应具有有效的强名称 是一个烦人的问题。
CA2210 Assemblies should have valid strong names is an annoying one.
我不使用禁止方法/事件名称中使用下划线的命名约定规则。 我已经习惯了“Button1_Click”。 Visual Studio 会自动插入下划线，因此您必须手动删除它们。 我只是觉得让他们一个人呆着更容易。 而且，我在创建方法/事件时添加下划线。
I don't use the naming convention rule that prohibits underscores in method/event names. I've gotten used to "Button1_Click". Visual Studio automatically inserts the underscores, so you have to manually remove them. I just think it's easier to leave them alone. And, I add the underscore when I create a method/event.
根据您正在构建的系统，您需要关闭一整套迂腐的废话。
我建议检查 FxCop 输出并自行决定。 一个人的迂腐是另一个人“必须具备的”。
There's a whole list of pedantic crap you'll want to turn off depending on the system you're building.
I'd suggest examining the FxCop output and deciding yourself. One mans pedantry is anothers "must have".
它抱怨“ID”并建议“Id”......即使遵循“两个字符缩写全部大写”规则：O）
It complains about "ID" and suggests "Id"... even though that follows the "two-character-abbreviations-are-all-capped" rule :O)