Visual Studio 2013: Organize Your Code with Named Regions


This feature was first introduced in Visual Studio 2005 and, over the years, I’ve heard plenty of arguments for and against using it. Those “against” think this can be used as a crutch to hide bad code and not adhere to good coding techniques. Those “for” think this is a great way to organize your code and get clutter out of the way. I’ll show you how it works and let you decide which group you fall into.




Creating Named Regions



In C++ you create regions by using “#pragma region” with label and “#pragma endregion” (case-specific):

5-16-2012 12-21-15 PM




For C# you can eliminate the “pragma” keyword, as well as the quotes around the region name if you desire, and just use “#region” with label and “#endregion” (case-specific):

5-16-2012 12-24-08 PM




Visual Basic is just as easy as C# and uses a similar syntax of “#Region” with label and “#End Region” (not case-specific):

5-16-2012 12-26-57 PM 

Note that the quotes around the region name are required in this example.




Value of Named Regions

The value of creating Regions is twofold. First, they travel with the code so are shared by all team members when using source control. Second, they become part of document outlining and can be collapsed:

 5-16-2012 12-30-40 PM 


or expanded to further organize you code:

5-16-2012 12-29-04 PM




Best Practice

Special thanks to Marcus Rangell for reminding me of this tip. As a best practice you might consider putting the name of the region in the End Region line as well:

5-16-2012 9-00-45 PM

This technique will work with C++ and C# but not with VB regions.


The best practice is particularly useful when you have nested regions:

5-16-2012 9-22-04 PM


The only down side is this doubles up the names in C++ when regions are collapsed:

5-16-2012 9-24-18 PM

You will not see this problem in C#.

Comments (13)

  1. I have the habit to also include the name in the #endregion, such as:

    #region LotsOfCode


    #endregion LotsOfCode

    So that when I run into an #endregion in the code, I know what code block it is the end of. Don't know if that is a good practice or not, but just how I do it..

    I still feel dirty every time I write #region though no matter what..

  2. zainnab says:

    Hey Marcus 🙂

    Yeah I know a lot of people who do that especially if they do nested regions. I think I'll update the post with that best practice. Thanks for reminding me!


  3. Terrence says:

    I use regions to group methods into different categories.  Some times I put a region around all of my properties and fields at the top of the class, some times I break code into private methods and public methods with regions.  I never use regions within a method.  If I find myself wanting to use a region in a method that usually means that code can be further broken out into a separate method.

  4. michail says:

    I've seen lots of people hating regions, but really, they're just another tool which is quite often useful.

    As for putting region name at the end of region, there's an extension in Visual Studio gallery which does it automatically (feature is called code block end tagger).

    It works with VS2010 – 2013, but I think only C# is supported in 2013 for now :

  5. David Mays says:

    Code regions are so disgusting. All they do is introduce visual clutter, and hide the issue that your class has too much junk in it.

    If your class is sized appropriately, you don't need to build a "map" for it with regions.

  6. Josh says:

    A best practice from the field: write code that is well enough organised and narrowly focussed enough that regions are never necessary.

    If you find yourself needing a region to group code, please consider breaking that code out into separate objects.

    To make life in codebases where regions are used extensively, there is a great VS plugin called I Hate #Regions at

    Alternatively, ReSharper comes with a great tool to remove regions, the File Structure window.

  7. Boris says:

    #pragma region MainMethod


    // endregion MainMethod

    #pragma endregion

    This is what I would use to avoid the doubles when regions are collapsed.

  8. Confused says:


    i lind of like and hate This feature as some usw that per function m(

    regardless of that it would cool to be able to collapse the region from the bottom. I always wondered why nobody is thinking of that. Because if you scroll up from the bottom and there comes a region you are not interested it, you will to find the top to collapse it. You would be a lot faster if you could collapse at the bottom. Skipping that entire region…that goes with functions as well…

    cheers.  🙂

  9. Alain says:

    Second that comment from Confused. It would be nice to be able to collapse regions from the bottom. VS has a nice feature where you can toggle between curly braces of a section (eg. in a for loop) by pressing CTRL+]. Unfortunately this doesn't work for regions…

  10. jBirgen says:

    Note in VB you Regions are not valid within methods.

    This corresponds with good coding techniques though: as an individual method shouldn't be so long that parts of it need be hidden or split and if you have a good region label, then you have a good candidate for extraction out to a different method.

  11. DynoEnviro says:

    Actually you can collapse from the bottom of a region in VS2013 (and I think 2012) by double clicking in the editor space between the treelines and the breakpoint column. Mouse over that area and a corresponding section of code will show a vertical highlight bar – double-click and that section of code will be collapsed.

  12. DynoEnviro says:

    …slight correction, the double-click needs to occur on the treeline itself where the vertical highlight is displayed – just give it a shot, you'll see what I mean.

Skip to main content