Type Member Layout Changes in ReSharper

Dec 5, 2014 at 7:39 AM
Edited Dec 11, 2014 at 8:38 AM
For ReSharper 9, the Type Member Reordering feature has received a big overhaul. As a result, the reordering patterns that are installed by StyleCop for ReSharper 8 can no longer be used in ReSharper 9 without some modifications.

In anticipation of an official update, I took some time to update the patterns for ReSharper 9: https://gist.github.com/StevenLiekens/2ff74b148297c8879d3c

  • These patterns do not use regions
  • There is 1 additional pattern of my own: do not reorder fields/properties with a [DataMemberAttribute], because those fields and properties are order-sensitive unless overridden by the DataMemberAttribute.Order property.
Dec 24, 2014 at 10:09 AM
I found SA1215 not handled well which is: All non-static readonly private fields must be placed before all non-static non-readonly private fields.
Dec 24, 2014 at 10:20 AM
Edited Dec 24, 2014 at 11:03 AM
It seems that ReSharper 9 is actually doing the wrong thing.

When you specify <ReadOnly /> for <Entry.SortBy />, ReSharper places readonly fields last instead of first.
When you don't specify <ReadOnly />, ReSharper does not sort by mutability, but other sorting rules still apply.
Dec 24, 2014 at 12:31 PM
Edited Dec 24, 2014 at 12:32 PM
A possible workaround is to split the "Fields" rule so that you have a pattern for "Readonly Fields" and a pattern for "Other Fields". That way, all readonly fields would be placed first, regardless of name/type/access. That's still not the kind of behavior you would get with older versions of ReSharper and the StyleCop plugin, but at least you wouldn't get SA1215 violations.
Dec 24, 2014 at 12:37 PM
Actually, never mind. This problem is fixed in ReSharper 9.0 Update 1. No need to modify the type member layout.
Jan 7, 2015 at 3:24 PM
I updated it to include the regions and added public operators to the "public members and operators" group: https://gist.github.com/DanielRose/e59777c0d47d0d4aa94a