Rearrange members with file and type layout patterns

Introduction to layout patterns

You can configure multiple layout patterns to be applied in different contexts (for example, you can have different patterns for classes and interfaces).

Within the patterns, you can specify matcher entries and snippets in the desired order, as well as regions/groups into which the matching items are wrapped/grouped.

The algorithm of applying the current pattern set works as follows:

1. If a file pattern exists, JetBrains Rider checks whether regions in the file should be removed, then it checks whether each of the matcher entries or snippets in the pattern matches any code item in the file.

2. If there are matching entries, their position in the file is changed according to the position of the corresponding matcher item in the file pattern.

3. If the same code item matches several matcher entries, then the matcher with higher priority or stronger constraints is applied. That is, if there is pattern A that matches public types and pattern B that matches public static types, then all public static types will be matched by the pattern B. To change this, you can raise the priority of the pattern A.

4. If there are matcher entries with the same set of constraints, the matching items are moved according to the position of the first of such matcher entries.

5. If regions or groups are specified, the matched items are grouped or wrapped with the regions accordingly.

   A group or a region allows you to specify priority for it. For example, if a group/region has higher priority than other matchers outside it, then JetBrains Rider first processes matchers inside the group/region, and then the rest of the matchers. The only difference between group an region is that the region wraps matched items into #region/#endregion.

6. Everything that is not matched is moved after the matched items. If you need to put the unmatched items elsewhere, you can create a matcher without constraints and set the desired position for it in the pattern.

7. After that, type patterns are applied, if any. JetBrains Rider checks whether each of the type patterns matches any type in the file. If there are several matching patterns for a type, the conflicts are resolved similarly to steps 3 and 4.

8. When the type match is established, JetBrains Rider checks whether regions in the type should be removed; then it checks whether each of the matcher entries in the pattern matches any member in the file.

9. If there are matching members, their position in the type is changed according to the position of the corresponding matcher item in the type pattern.

10. Regions, groups and unmatched members are dealt with similarly to steps 5 and 6.

File and type layout preferences

The default member layout rules are based on the numerous best practices and can be recommended in most cases. However, if your personal preferences or company standards differ from JetBrains Rider defaults, you can configure code reordering patterns based on the default ones as well as create new patterns for specific cases.

All modifications to the layout patterns are done in the Editor | Code Style | C# | File Layout page of JetBrains Rider settings Ctrl+Alt+S. After the editing is done, click Save in the Settings dialog to apply the modifications and let JetBrains Rider choose where to save them, or save the modifications to a specific settings layer using the Save To list. For more information, see layer-based settings.

Configure file and type layout by editing the source XAML

We recommend that you load one of the default patterns and check the tags used in this format. They are rather self-explanatory, for example, the Entry tag defines a matcher entry and the Entry.Match specifies what code items should be matched. the Entry.SortBy tag specifies how the matched items should be sorted, and so on. Consider the example below:

This XAML code matches constructors and sorts them in such way that first go static constructors.

Scenario: group items in regions by partial name match

Consider a class where all methods start with test, and then some of them have one common substring, others — another one, and so on:

public void test_groupOne_nameOne(){ /*...*/}

public void test_groupTwo_nameTwo(){ /*...*/}

public void test_groupOne_nameTwo(){ /*...*/}

public void test_groupTwo_nameOne(){ /*...*/}

You can use type layout to wrap each set of methods in a region and use the common substrings as region names.

To do so, add the following pattern to the XAML:

<TypePattern>
  <Region Name="${Name}" Priority="100">
    <Region.GroupBy>
      <Name Is="(test\w+?)_.*" />
    </Region.GroupBy>

    <Entry>
      <Entry.Match>
        <Name Is="test\w+?_.*" />
      </Entry.Match>
    </Entry>
  </Region>
</TypePattern>

After applying the layout to the class, the methods will be sorted and wrapped in the corresponding regions:

#region test_groupOne

public void test_groupOne_nameOne(){ /*...*/ }

public void test_groupOne_nameTwo(){ /*...*/ }

#endregion

#region test_groupTwo

public void test_groupTwo_nameOne(){ /*...*/ }

public void test_groupTwo_nameTwo(){ /*...*/ }

#endregion

Reorder file and type members

To apply your file and type layout settings in the desired scope, use either run code cleanup with the Built-in: Full Cleanup profile or create and run a custom profile solely targeted at your specific task as described below.

If you want to apply file layout without opening the Reformat and Cleanup Code dialog to choose a profile, you can bind the created profile to the silent cleanup and run it by pressing Ctrl+E, F. You can also create a custom cleanup profile that would combine applying file layout with other code style tasks.