您希望 FxCop/Gendarme 有什么规则?
您希望 FxCop 和/或 Gendarme 添加什么可定义的静态代码检查规则?
为什么您希望看到添加的规则,例如有什么好处等?
你的规则如何实施?
What definable static code checking rule do you wish to see added to FxCop and/or Gendarme?
Why to do you wish to see the rule added, e.g what are the benefits etc?
How could your rule be implemented?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
我想很快地定义并实施我自己的规则。我在 FxCop 上尝试过一次,但我发现 API 不是很清晰 - 并且周围没有太多文档。我使用了 FxCop 1.36,也许事情发生了变化...
所以我希望看到 FxCop 有一个清晰且易于使用的界面...那就太好了:)
我尝试实现的规则是:
基本上我想对非公共成员强制执行 xml 注释。
I'd like to define and implement my own rules very quickly. I tried this once for FxCop, but I found the API not to be very clear - and there was not too much documentation around. I used FxCop 1.36, maybe things changed ...
So I'd like to see FxCop having a clear and easy to use interface ... that would be great :)
The rules I tried to implement were:
Basically I wanted to enforce xml-comments on non-public members.
就我个人而言,我希望看到在
using
语句中不使用IDisposable
实现。因此,如果您有这样的代码:
它会告诉您在
using
语句中使用它。这样做的好处是,它会提醒您注意您可能不知道的情况,即应处置的对象未及时处置的情况。
然而,很多时候,在 using 语句中不声明 IDisposable 实现是有效的,这样的规则很快就会变得很痛苦。大多数情况下,这种情况是将 IDisposable 实现作为方法的参数。
我不是的意思是类的用法,其中实现细节消除了调用
Dispose
的需要,(例如MemoryStream
或DataContext< /代码>);这些实现了 IDisposable,并且应该始终调用它们的 Dispose,无论实现细节如何,因为根据公开的合约进行编码总是更好。
Personally, I would prefer to see not using
IDisposable
implementations inusing
statements.So if you had code like this:
It would tell you to use it in a
using
statement.The benefit would be that it would alert you to cases you might not be aware of where objects that should be disposed are not being disposed in a timely manner.
However, there are enough times where it's a valid situation to NOT declare
IDisposable
implementations in a using statement for a rule like this to become a pain very quickly. Most often, this case is taking anIDisposable
implementation as a parameter to a method.What I do not mean is usages of classes where the implementation details remove the need for calling
Dispose
, (e.g.MemoryStream
orDataContext
); those implementIDisposable
and should always haveDispose
called on them, regardless of the implementation details, as it is always better to code against the contract exposed.我真的希望二进制分析足够智能,能够识别接口的可能性。
它是否可以通过接近定义的类型及其成员来确定是否存在可以外推到接口中的公共内容。
显然,这不应该只是一个警告,因为有时希望明确不使用接口。
I'd really like the binary analysis to be smart enough to recognize the possibility of an interface.
If it could determine from approaching the defined types and their members, if there are commons that could be extrapolated into an interface.
Clearly, this should not be more than a warning, since it is sometimes whished to explicitly not use an interface.
考虑到这一点,我也希望看到二进制分析足够智能,可以检查访问修饰符可能的降级。
确定类、属性或方法是否可以受到更多限制应该不难。
Upon thinkin about this, I too would like to see the binary analysis to be smart enough to check possible downgrade of access modifiers.
It shouldn't be to hard to determine if a class, property or method could be more restricted.