如何解决违反 StyleCop SA1305 的问题(匈牙利语)
我的代码包含一个名为“m_d3dDevice”的变量。
StyleCop 抱怨这个名字:
SA1305:变量名 'm_d3dDevice' 以前缀开头 看起来像匈牙利表示法。 删除前缀或将其添加到 允许的前缀列表。
(请注意,我已手动禁用 SA1308(“m_”),这是我愿意违反的少数规则之一。)
我不能允许“d3d”作为匈牙利语选项卡中的例外,因为它只允许 1 或 2 个字符前缀,并且允许“d3”没有帮助。我已经尝试了所有我能想到的将“d3d”添加到我的 CustomDictionary 文件中(无论如何,文档暗示 CustomDict 不用于规则 1305)。
有什么建议可以让 StyleCop 允许这样做吗?现在不必 F2 我的变量是一件值得自豪的事情。
My code contains a variable named "m_d3dDevice".
StyleCop complains about this name:
SA1305: The variable name
'm_d3dDevice' begins with a prefix
that looks like Hungarian notation.
Remove the prefix or add it to the
list of allowed prefixes.
(Note I have manually disabled SA1308 ("m_"), one of the few rules I'm willing to disobey.)
I can't allow "d3d" as an exception in the Hungarian tab, as it only allows 1 or 2 char prefixes, and allowing "d3" didn't help. I've tried everything I can think of to add "d3d" to my CustomDictionary file (and anyway the docs imply the CustomDict isn't used for rule 1305).
Any suggestions to make StyleCop allow this one? It is a matter of pride now to not have to F2 my variable.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
您还可以根据具体情况抑制 stylecop。例如,
如果您有许多令人不快的名字,这可能不是一个有吸引力的选择,但对于一两个,通常没问题。
You can also suppress stylecop on a case-by-case basis. e.g.
This might not be an attractive option if you have numerous offending names, but for one or two, it's generally fine.
您还可以使用包文件中的
Settings.StyleCop
来配置设置。您可以通过将以下代码添加到
Settings.StyleCop
文件来抑制特定单词:您可以通过将以下代码添加到
Settings.StyleCop< 来抑制
Hungarain
规则本身/代码> 文件You can also use the
Settings.StyleCop
in the package files to configure the settings.You can suppress specific words by adding below code to the
Settings.StyleCop
file:You can suppress the
Hungarain
Rule itself by adding the following to theSettings.StyleCop
file你可以看看我的工具,StyleCop+。它包含灵活的命名规则,允许您强制所有私有字段以“m_”(或您希望的任何内容)开头命名,而不是禁用名称检查(就像您所做的那样)。
关于“d3dDevice”——这是一个非常有趣的案例。从逻辑上讲,它分为以下单词 - { "d", "3", "d", "Device" } 或 { "d3", "d", "Device" }。第二个“d”似乎不遵循“camelNotation”。
但我坚信静态分析(特别是命名)应该足够灵活,以满足用户的需求。目前,StyleCop+ 可以通过以下方式支持您的情况 - 例如,您可以将“例外”(任意数量)添加到私有字段的命名模板中,以便它看起来像:
这更有可能是解决方法,但我会考虑你的“d3d”案例 - 也许 StyleCop+ 会支持这样的东西。
You could take a look at my tool, StyleCop+. It contains flexible naming rules that will allow you to force all private fields be named starting with "m_" (or whatever you wish) instead of disabling name checking (like you did).
Regarding "d3dDevice" - it's a very interesting case. Logically, it splits to the following words - { "d", "3", "d", "Device" } or { "d3", "d", "Device" }. And the second "d" seems not to follow "camelNotation".
But I strongly believe that static analysis (particularly naming) should be flexible enough to satisfy user needs. Currently StyleCop+ can support your case in the following way - for example, you can add "exception" (as many as you want) to naming template for private fields, so that it will look like:
This is more likely to be workaround, but I will think about your "d3d" case - and maybe StyleCop+ will support something like this.
添加抑制属性应该在所有方法之上完成,这将需要时间和漫长的过程。
如果您想从项目中删除此规则,请尝试此
Adding suppression attribute should be done on top of all methods which will take time and a long process.
If you would like to remove this rule from your project try this