Question

I recently inherited some C# code where nearly every item in a file was wrapped in an individual #region/#endregion block — every class, every function, every property, every enum, but not the fields. Each of these was in turn wrapped in a “grouping” #region (e.g. “Properties”, “Constructor”, “Methods”, etc.). There are multiple overloads of a single function with different argument lists, but they’re each wrapped in individual regions with the same name, rather than a single region for all three overloads. The person who wrote this code is no longer with the company, and from the history in source control, it appears that these were present in the initial submission, and the practice continues through successive versions of the code as new properties and methods are added.

Any idea why this might be done? Some thoughts:

1. An overzealous VS feature (or code-cleanup tool) automatically inserted the #region/#endregion blocks, and the author didn’t remove them.
2. There’s an IDE that folds regions but not functions, so this was necessary to get syntax folding.
3. This is a method of stubbing out the structure of your code prior to implementing it.

EDIT: I chose Jonathan’s answer because it contributed a new reason why someone might have chosen to do this. Thanks for the discussion!

Answer 1

When it comes to non-auto-implemented properties it can make the code easier to navigate. For instance a lot of the following code (inside the region) is just extraenuous fluff – which always looks the same (as properties really shouldn’t have side-effects). Having a single line saying “Property – Name” is much nicer to navigate.

#region Property - Name
private string _name;
/// <summary>
/// Gets or sets the name of the customer.
/// </summary>
/// <remarks>
/// This should always be the full name of the customer in the format {First Name} {Last Name}.
/// </remarks>
/// <example>
/// customer.Name = "Joe Bloggs";
/// </example>
/// <seealso cref="Customer"/>
/// <value>
/// The name of the customer.
/// </value>
public string Name
{
    get
    {
        return _name;
    }
    set
    {
        _name = value;
    }
}
#endregion

However, as far as the ‘member type’ (Methods, Properties, Constructors, Fields) go I feel it makes the code harder to navigate; however other people feel it makes it easier.

In the end it’s a coding standard and religous. If you don’t like it, don’t use it one your personal projects. If you are required to use it due to a standard then use it.