FXCop-您对此有多认真? [英] FXCop - How seriously do you take it?

问题描述

我一直在使用FXCop对我的应用程序进行性能分析，似乎在抓东西方面做得不错，但是，在某些情况下，我完全不同意它的建议. (这比驱动应用本身的标准和驱动应用的规则更多.)

例如:

I''ve been profiling my apps with FXCop, it seems to do an okay job of catching stuff, however, I completely disagree with it''s suggestions in some cases. (This is more of an issue with the standards, and rules that drive the app, than the app itself.)

For example:

报价:

信息:抽象类型的公共构造函数无法生成
有道理，因为您无法创建抽象的实例
类型."

Info : "Public constructors for abstract types do not make
sense because you cannot create instances of abstract
types."

我不同意.

http://msdn.microsoft.com/library/ms182126%28VS.100%29.aspx [ ^ ]

如果您按照他们给我的链接进行操作，那么会继续下去，等等，关于类型是如何不当"设计的，等等.

如果创建抽象类并使用虚拟方法，则可以在base(abstract)类的后台进行大量工作，从而使继承自该类的类更加整洁. (为简单起见，这段代码必须存在于基类或实际类中，对我而言，将任何可能的抽象都对我来说是合乎逻辑的.(和我的理智.))

因此，有时候，当我需要完成某些事情时，我会按照它不应该做的事情做，并且效果很好，并为我提供了更简洁的代码.除了MS不喜欢它之外，我没有其他缺点.

我敢肯定你们中的一些人可能在这里有不同的看法，但是，实际上，这不是重点，这只是我们正在讨论的一个例子.

----

那么，回到我的问题，您对此有多认真?您是否按照它说的做所有事情(当然，不包括误报)，或者您喜欢挑剔，等等. ?

当它们有意义并且具有合理的推理等能力时，我就会遵循标准，但是当它们出于诸如以下的任意原因限制了我作为程序员的能力时，我就不会这样做:

I disagree.

http://msdn.microsoft.com/library/ms182126%28VS.100%29.aspx[^]

If you follow the link they gave me, it goes on to blah, blah, about how the type is "improperly" designed, etc,.

If you create an abstract class, and use virtual methods, you can do a lot of work behind the scenes in the base(abstract) class, keeping the class that inherits from it much cleaner. (This code must exist, either in the base class, or in the actual class, it''s logical to me, to abstract anything you can, for simplicities sake. (And my sanity.))

So, on the occasion, when I need to accomplish certain things, I do exactly what it claims you shouldn''t, and it works fine, and gives me cleaner code. I see no downsides, aside from MS not liking it.

I''m sure some of you might have differing opinions here, but, really, that isn''t the point, this is just an example of what we''re discussing.

----

So, back to my question, how seriously do you take it? Do you do everything it says(false positives not included, of course), or do you cherry pick, etc,. ?

I follow standards when they make sense, and have sound reasoning, etc, but, not when they''re limiting my ability as a programmer for arbitrary reasons like:

报价:

信息:抽象类型的公共构造函数无法生成
有道理，因为您无法创建抽象的实例
类型."

Info : "Public constructors for abstract types do not make
sense because you cannot create instances of abstract
types."

您缺乏创造力和远见，这不是我失败的MS，为什么这是标准? MS的人没有想到使用抽象类来抽象东西吗?真的吗?

所以真的，这是关于标准的，你们是否始终遵循标准，或者您像我一样全力以赴，并且在您认为这是正确的解决方案时做自己的事?

Your lack of creativity, and vision, is not my failing MS, why is this a standard? No one at MS ever thought of using an abstract class to abstract stuff? Really?

So really, this about standards, do you guys always follow standards, or do you go all rebel like me, and do your own thing when you think it''s the right solution?

推荐答案

请参阅上面的评论:

See my comment above:

1. 确定哪些FxCop规则对于您的项目/公司是错误，警告或被忽略的
2. 确保所有规则集文件均符合上述评估要求
3. 错误和警告严重

干杯
安迪

Cheers
Andi

我同意！我发现了一些FxCop规则，这些规则不仅不对，它们是愚蠢的！

我记得另一个案例. FxCop认为""out"参数表明存在设计缺陷.我强烈认为，这对于某些语言来说是有意义的，但是由于C#在签名和调用代码中都要求使用"out"关键字，因此消除了所有问题.在许多情况下，出局"比其他任何事情都要好.

我曾经看到过很多类似的问题.正如您所指出的那样，我也面对这一点，对其进行了分析，并得出了与您相同的结论.

同时，FxCop可能非常有用.它发现了很多我无法用肉眼看到的问题，例如性能(简单的事情，在不使用"this"的方法中缺少"static"，这显然是我的错误)，拼写等等.

结论:使用FxCop，但对项目选项进行微调，并从实践中消除那些愚蠢的规则.这也是乔建议您的.如果以这种方式使用FxCop，它将为您提供帮助，而不是麻烦.

—SA

I agree with you! I found some FxCop rules which are not just wrong, they are idiotic!

I remember another case. FxCop "thinks" that the "out" parameters is a sign of a design flaw. In my strong opinion, this would make sense for some languages, but as C# requires "out" keyword in both signature and calling code, all the problems are eliminated. There are many cases when "out" is better than anything else.

I used to see many problems like that. As the one you pointed out, I faces with that, too, analyzed it and came to the same conclusion as you did.

At the same time, FxCop can be very useful. It found out many problems I failed to see with naked eye, such as performance (a simple thing, missing "static" in methods not using "this" — apparently my mistake), spelling and a lot more.

Conclusion: use FxCop but fine-tune the project options and eliminate those idiotic rules from your practice. This is what Joe advised you, too. If you use FxCop in this way, it will can be for help, not for hassles.

—SA

这篇关于FXCop-您对此有多认真?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！