Category: LifeHacks

I’ve been using Regionerate for some time, and I’m addicted to it. Literally when I have to write some code on a computer that doesn’t have Regionerate installed I feel odd. This tool is simply pure honey and nuts. Only thing I would change is it’s default keyboard mapping (ctrl+R for running it), because it collides with Visual Studio/ReSharpers “Refactor” shortcut. So every time I install it I have to go to VS settings and change it to something else (alt+3 at the moment).

Main reason for this post however is not to praise Rauchy and his tool, but to talk a little bit about it’s customization capabilities. Regionerate is Xml driven, that is, its regioneration (strange word, huh?) settings are kept in a xml file. It comes with xsd so when you edit it in VS you’ll get intellisence, which is pretty sweat and will save you a lot of time.

The simplest possible  Regionerate settings file would look like this:

<CodeLayout xmlns="http://regionerate.net/schemas/0.6.3.8/CodeLayout.xsd">

    <ForEachClass>

        <CreateRegion>

            <PutFields>

            </PutFields>

        </CreateRegion>

    </ForEachClass>

</CodeLayout>

It creates a region and puts all fields into it, like below:

namespace Xtoff.Tmx.Helpers

{

    public class TmxLanguage

    {

        #region [rgn] Unnamed Region (1)

        private readonly string _value;

        #endregion [rgn]

        public TmxLanguage(string value)

        {

            _value = value;

        }

        public string Value

        {

            get { return _value; }

        }

    }

}

All fields were put in a single region, and all other members were left below. Hooray!. However I guess very few would be satisfied at this point.

Before we move on, however, there are a few facts to note.

First of all, regions name: [rgn] Unnamed Region (1)

[rgn] is a standard prefix for regionerate to mark it’s regions. It was introduced because without some kind of differentiator regionerate would break your manually created regions when regionerating your file. Thanks to this, it will only look into parts of your class that are not inside any region, or are inside a Regionerate-created region. You can change this prefix, or remove it. Keep in mind however, that then every region will be treated as a Regionerate-created region.

Next thing is region’s name. We didn’t set it, so Regionerate set it to default. I don’t have to tell you that you DO want to name your regions :).

And finally (1) indication how many elements is in a region. VERY useful when dealing with large files.

Next step would then probably be setting a name, and looking at other options we have.

If you go back to CreateRegion, hit space and wait for intellisence to come up you’ll be presented with 4 options:

Separating lines: Allows you to specify how many free lines you want Regionerate to leave between members in a regions.

ShowCount: Flag allowing you to turn of showing count of members inside of a region, defaults to true, and I don’t recommend changing it.

Style: this is one of the best and little known features.

Three valid options are Visible, Comment and Invisible. Visible is the default option, and it will wrap your code with a region like seen above

Comment will clean up your code but instead of enclosing it within a region it will only put a comment on top of all fields, like this:

        // [rgn] Unnamed Region (1)

        private readonly string _value;

Invisible, will clean up your code, but it woun’t put any regions not comments.

Title: sets the title for region 🙂

Going down the Xml tree, we can define what we want to put in out region. In our example we chose fields, but you can put basically every class member (field, property, method, event and so on), or inner region. You can do multiple Put* into a region.

Now we’re getting into really interesting stuff, that is defining filters for specific elements we want to put in a region. In the example above we chose to keep all fields in this region, but we could have come up with something much more sophisticated, like region for non serialized public fields with names meetings certain regular expression.

I won’t explain every single option in detail because there are so many that it would take too long. There are also diferences between types of elements (for example for Properties you can filter by accessors). In 9 cases out of 10 you will be able to create rules you want. You can’t create rules like “Region for methods that subscribed to some events” unles you have a naming convention for those, because it would require analysis on a higher level of abstraction, but nonetheless it’s pretty sweat.

And for those interested, I attach my Regionerate settings file.