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.
Technorati Tags:
Regionerate,
Tools,
.NET
I feel very happy to find it, since it does exactly this, what I wanted for a long time, and it’s something that neither Refactor! Pro, nor ReSharper allows you to do. At the moment it’s in its infancy (current version is 0.6beta) but even now it’s very handy, works quite fast, has integration with NAnt, and enables you to customize it’s behavior by editing xml file. It has even xml schema attached, so you’ll get intellisence and description of elements as you type.
With two clicks you can go from code like in 1st screenshot, to code like this, with elements gathered together, sorted by type or alphabetically and optionally embedded in a #region (with count of elements inside. And you can have your own, custom regions, for example if you want to keep read only properties separated from other, you can, if you have many methods (or any other elements) you can separate them by accessibility (private public, protected) you can keep static methods separately of methods overriding or hiding (with ‘new’ keyword) base class implementations – you can totally do that. Future releases will give you even more options and flexibility, so it’s definitely project worth keeping an eye on. Oh, and if you want to see it in action before you download it, 
) you can contribute to the project, either by writing some code for the IDE itself, or by writing a plugin,