Share via


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

 

C++

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

5-16-2012 12-21-15 PM

 

 

C#

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

 

 

VB

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

  • Anonymous
    July 11, 2013
    I have the habit to also include the name in the #endregion, such as: #region LotsOfCode <code> #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..

  • Anonymous
    July 11, 2013
    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! Z

  • Anonymous
    July 11, 2013
    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.

  • Anonymous
    July 12, 2013
    Great

  • Anonymous
    July 16, 2013
    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 : visualstudiogallery.msdn.microsoft.com/c6d1c265-7007-405c-a68b-5606af238ece

  • Anonymous
    July 18, 2013
    The comment has been removed

  • Anonymous
    July 18, 2013
    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 visualstudiogallery.msdn.microsoft.com/0ca60d35-1e02-43b7-bf59-ac7deb9afbca Alternatively, ReSharper comes with a great tool to remove regions, the File Structure window.

  • Anonymous
    July 18, 2013
    #pragma region MainMethod <code> // endregion MainMethod #pragma endregion This is what I would use to avoid the doubles when regions are collapsed.

  • Anonymous
    July 23, 2013
    Hy, 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.  :)

  • Anonymous
    March 07, 2015
    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...

  • Anonymous
    April 07, 2015
    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.

  • Anonymous
    June 11, 2015
    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.

  • Anonymous
    June 11, 2015
    ...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.