tags:

views:

92

answers:

2

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.

+3  A: 

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.

Joe
+1 100% agree! Stops endless discussions on doing it this way or doing it that way.
The Chairman
+1 Go with what it says, it's amazing how soon you will start writing code that style cop likes.
Mark Dickinson
+4  A: 

In the above example sticking to stylcecop makes you less productive plus the code becomes less readable

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.

blowdart
+1 for pointing out free will.
Colin Mackay
Of course we are not forced to use stylecp but I think we all agree that it is quite useful. Especially if we write code that is public or used by a lot of team members. There is just one or the other rule that should work slightly different. Of course we can disable rules and write our own rules. But the default rules are there for a purpose. They can be considered as hints for best practices. That's why it would be a good idea to make them as widely appliable as possible.
bitbonk
Some of the default rules are there to make up for deficiencies in the Microsoft diff too. If you use a different one (no pun intended), then should you use updated rules? Probably not.The default rules are there because they enforce MS's inhouse style. Is it best practice to put an Microsoft inhouse style comment at the top of every source file? Nope. They's not all best practice hints. It's a style checker, nothing more. It's not FXCop where those definitely are best practice rules.
blowdart