StyleCop 与 DependencyProperties
我总是倾向于将属于依赖属性（注册、clr 属性、更改回调、强制回调等）的所有内容分组到一个区域中。但这违反了 stylecop 成员排序规则。这也是生成多个成员的代码片段的普遍问题，因为代码片段无法在我的文件中的不同位置生成代码。您对此有何看法？你是否破坏了 stylecop 规则，或者你是否将所有内容都放在“正确”的位置？
另外，我个人认为 stylcop 不应该抱怨这一点：
/// <summary>
/// RepeatX Dependency Property
/// </summary>
public static readonly DependencyProperty RepeatXProperty =
DependencyProperty.Register(
"RepeatX",
typeof(int),
typeof(GeometryViewbox),
new FrameworkPropertyMetadata
{
DefaultValue = 1,
AffectsRender = true,
AffectsParentMeasure = true,
PropertyChangedCallback = OnRepeatXChanged,
CoerceValueCallback = CoerceRepeatXValue
});
Stylcop 应该为我们生成额外的工作要做。在上面的示例中，坚持使用 stylcecop 会降低您的工作效率，而且代码的可读性也会降低，因为您被迫将上述代码放入静态构造函数（而不是字段初始化）中，以便能够将 FrameworkPropertyMetadata 放入临时变量中。每个依赖属性的一个额外的临时变量并不会使代码更具可读性/可维护性，而且您不能再使用codesnippets。
I always tend to group all stuff that belongs to a dependency property (registration, clr property, change callback, coerce callback etc.) into one region. But this violates the stylecop member ordering rules. This is also a general problem with codesnippets that generate multiple members, since the snippets can not generate code at different places in my file. What is you philosophy on this? Do you disbale the stylecop rules or do you put everything at its "right" place?
Also I personally think that stylcop should not complain about this:
/// <summary>
/// RepeatX Dependency Property
/// </summary>
public static readonly DependencyProperty RepeatXProperty =
DependencyProperty.Register(
"RepeatX",
typeof(int),
typeof(GeometryViewbox),
new FrameworkPropertyMetadata
{
DefaultValue = 1,
AffectsRender = true,
AffectsParentMeasure = true,
PropertyChangedCallback = OnRepeatXChanged,
CoerceValueCallback = CoerceRepeatXValue
});
Stylcop should generate addtional work for us to do. In the above example sticking to stylcecop makes you less productive plus the code becomes less readable, because you are forced to put the above code in the static ctor (instead of field initialization) to be able to make FrameworkPropertyMetadata into a temp variable. One additional temp variable for each dependency property doesn't make the code more readable/maintainable plus you can't use codesnippets anymore.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您真的相信这一点，那么就不要使用它。没有人强迫您使用它，就像没有人强迫您停止使用匈牙利表示法（如果您愿意）一样。如果您是一名孤独的开发人员，并且没有人会看到您的源代码，然后对其进行格式化，但让您高兴，那么您就是必须维护它的人。如果您在一个较大的团队中，那么您应该制定一些编码标准，以便您可以轻松阅读彼此的代码 - 但如果您不愿意，则不必使用 stylecop。
仅仅因为某个工具可用并不意味着它能够满足您的需求并且您必须使用它。你可以自己思考。
If you truly believe that then don't use it. No-one is forcing you to use it, just like no-one is forcing you to stop using Hungarian notation if you want to. If you're a lone developer and no-one will see your source code then format it however makes you happy, you're the person that has to maintain it. If you're in a larger team then you should get some coding standards in place so you can read each other's code easily - but you don't have to use stylecop for that if you don't want to.
Just because a tool is available doesn't mean it's going to suit your needs and you must use it. You are allowed to think for yourself.
我们倾向于按照 Stylecop 的建议来安排一切。这样就更容易了。减少麻烦。如果您在所有情况下都遵守规则，您总是知道在哪里寻找东西。此外，您可以使用该下拉菜单直接跳转到成员声明。
FWIW，我们也从不使用区域。这样事情就不那么混乱了。
We tend to put everything as Stylecop suggests. It's just easier that way. Less hassle. And if you follow the rules in all cases, you always know where to look for things. Besides, you can use that drop down menu to jump straight to member declarations.
FWIW, we also never use regions. Things are less cluttered that way.