您希望 FxCop/Gendarme 有什么规则?

发布于 2024-08-21 22:17:38 字数 97 浏览 6 评论 0原文

您希望 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

彩扇题诗 2024-08-28 22:17:38

我想很快地定义并实施我自己的规则。我在 FxCop 上尝试过一次,但我发现 API 不是很清晰 - 并且周围没有太多文档。我使用了 FxCop 1.36,也许事情发生了变化...

所以我希望看到 FxCop 有一个清晰且易于使用的界面...那就太好了:)

我尝试实现的规则是:

  • DocumentInternalMethods
  • DocumentInternalTypes
  • ...

基本上我想对非公共成员强制执行 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:

  • DocumentInternalMethods
  • DocumentInternalTypes
  • ...

Basically I wanted to enforce xml-comments on non-public members.

橘寄 2024-08-28 22:17:38

就我个人而言,我希望看到在 using 语句中不使用 IDisposable 实现。

因此,如果您有这样的代码:

var fs = new FileStream(...);

// Other code.

fs.Dispose();

它会告诉您在 using 语句中使用它。

这样做的好处是,它会提醒您注意您可能不知道的情况,即应处置的对象未及时处置的情况。

然而,很多时候,在 using 语句中不声明 IDisposable 实现是有效的,这样的规则很快就会变得很痛苦。大多数情况下,这种情况是将 IDisposable 实现作为方法的参数。

不是的意思是类的用法,其中实现细节消除了调用Dispose的需要,(例如MemoryStreamDataContext< /代码>);这些实现了 IDisposable,并且应该始终调用它们的 Dispose,无论实现细节如何,因为根据公开的合约进行编码总是更好。

Personally, I would prefer to see not using IDisposable implementations in using statements.

So if you had code like this:

var fs = new FileStream(...);

// Other code.

fs.Dispose();

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 an IDisposable 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 or DataContext); those implement IDisposable and should always have Dispose called on them, regardless of the implementation details, as it is always better to code against the contract exposed.

梦旅人picnic 2024-08-28 22:17:38

我真的希望二进制分析足够智能,能够识别接口的可能性。

它是否可以通过接近定义的类型及其成员来确定是否存在可以外推到接口中的公共内容。

显然,这不应该只是一个警告,因为有时希望明确不使用接口。

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.

阳光的暖冬 2024-08-28 22:17:38

考虑到这一点,我也希望看到二进制分析足够智能,可以检查访问修饰符可能的降级。

确定类、属性或方法是否可以受到更多限制应该不难。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文