Any .NET '#region directive' convention ideas ?

Question

I really appreciate the possibility to define regions in your code, as it improves the readability insanely.

Anyways, I'd like to have everyone using the same convention in all classes (with the predefined order of all regions) like:

• Private Fields
• Constructors
• Class Properties
• Event Handlers
• etc...

Do you have any proposition how this division could look like (What regions have sense and what names should they have) and in which order should they be defined ?

Answer 1

Someone once said that having a convention like the one above:

• Private Fields
• Constructors
• Class Properties
• Event Handlers
• etc...

is like setting a table where all the plates are together, all the spoons are together, all the knives are together and all the forks are together.

My take on the #region issue is to put related methods, event definitions, and properties together in one region. However, having to do this at all would indicate a code smell (either your class is too big or does too many things) but this is a good first step into refactoring it into a better class.

Answer 2

My convention is not to use them.

If you find your class getting too big such that you need to hide vast parts of it through regions I propose your class is too complex and should be broken apart.

Answer 3

Thats controversial , some people say that regions are a bad style...

Answer 4

You might be interested in this do you say no to c# regions.

I think that so long as you're consistent accross your project it doesn't matter too much which order you write them in. Also be very very wary of overusing them (hence the initial link!).

There's nothing worse than finding a closed constructor region which is hiding only one line of code.

I think in the end it's down to personal taste. As I've said, consistency is the key!

Answer 5

Think of them as another form of comments: additional information mixed in with your code, which has no formal checking performed on it. Hence it will likely drift out of date with the code.

So NEVER duplicate in comments or region directives that which is already stated in the code.

Only add extra information.

In particular, using regions to restate the fact that certain members are properties, events, etc. is completely pointless. The most common problem there is that you create a region for "private methods", and then you edit one of them to make it public. Now you have to move it, which means that in a diff with the old version, the simple change is much harder to discern.

Answer 6

#region Lotsa boring code and lookup tables

I use it to save screen real estate, nothing else :)

Answer 7

Whenever I see regions I think that the code is either generated or in need of re-factoring.

Avoid using them and when you feel the need for them, re-examine what you're doing and try to split your class in to smaller ones. Ultimately this will help with the readability of the application more than using regions will.

Answer 8

I wrote my own region code snippet for VS 2008 which I always use:

<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippets  xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet"&gt;
<CodeSnippet Format="1.0.0">
    <Header>
        <Title>#class region</Title>
        <Shortcut>#classregion</Shortcut>
        <Description>Code snippet for #region in classes</Description>
        <Author>Simon Linder</Author>
        <SnippetTypes>
            <SnippetType>Expansion</SnippetType>
            <SnippetType>SurroundsWith</SnippetType>
        </SnippetTypes>
    </Header>
    <Snippet>
        <Declarations>
            <Literal>
                <ID>name</ID>
                <ToolTip>Region name</ToolTip>
                <Default>MyRegion</Default>
            </Literal>
        </Declarations>
        <Code Language="csharp">
            <![CDATA[#region Variables
                    $selected$ $end$
                #endregion

            #region Construction/Destruction
                    $selected$ $end$
                #endregion

            #region Properties
                    $selected$ $end$
                #endregion

            #region Public Methods 
                    $selected$ $end$
                #endregion

            #region Private/Proteced Methods
                    $selected$ $end$
                #endregion]]>
        </Code>
    </Snippet>
</CodeSnippet>

As you can see I do use regions for Variables, Construction/Destruction, Properties, Public and Private methods. I often add another sub-region into the private region called events. The order of regions also works fine with StyleCop.

Answer 9

Personally I wouldn't recommend making code regions part of your code convention. The main reason being that regions hide code, which could potentially lead to issues like:

• Developers might miss some important part of the source code
• The average amount of LOC in the same file tends to increase

If you are interested in enforcing a coding style convention in your team, have a look at Microsoft StyleCop. Note that the tool currently only works for C#.

Answer 10

I use the following regions:

Private Member Variables
Constructor
Public Properties
Private Methods
Public Methods
Events

The reason is because of better organization of code.
I work with files that may have over 2000 lines of code and it is very difficult to maintain the code without regions.

Answer 11

I think there is no need in regions. Them are not legible. If you need (think, do you realy need?) an amount code in your class, you can use 'partial' class to split the class logic units.