<< Jeff Julian in Columbus Next Week | Home | Imagine Cup >>

Using Regions in VS.NET

If you've spent much time in Visual Studio .NET, you've probably discovered the ability to create regions in your code that can be collapsed using the outlining features in Visual Studio. It lets you hide some of the clutter in a class file. VS.NET puts most generated code in a region to hide it away from developers.

Over the past couple years using VS.NET, I've struggled with how to best use this feature. It seems that there are couple ways to approach regions:

  • Public/Private/Protected - One region for each access modifier keyword. This would organize your code in a similar way to how C++ code is organized.
  • Member Type - One region for each type of member: Fields, Properties, Methods, etc.
  • Behaviour - A region that groups members by the a more granular behavior or role in the class. For example, grouping all CRUD methods together in one region and all Calculation methods in another region.
  • There are probably others...

I go back and forth on what the best organization is. It seems like in some situations one strategy is clean and simple, yet in another situation it just gets in the way. It would be nice if I could settle myself on one strategy for regions or just convince myself not to use them at all.  I wonder how others have developed best practices around this feature.

One last thought. It seems like some developers are so good at organizing and writing code that there is no need for regions to hide clutter. I hate you. ;)

Print | posted on Wednesday, March 24, 2004 11:14 AM

Feedback

# re: Using Regions in VS.NET

left by Aaron Weiker at 3/30/2004 8:17 PM Gravatar
I have come to this conclusion, it doesn't matter how I group the code in a region. I keep coming back to the same thing, I always like it better the way I didn't do it. At least that's how I feel in ASPX pages. That was until I just started doing the really obvious. I know have a region for each method/property. I leave all protected/private declarations looking the way they normally do. I seem to like this better as it still leaves a somewhat larger file, but hides the implementation details for you. If it's a method I give the region name some ()'s, meanwhile if it's a property I just leave it blank. So far since I've started doing this I have been pretty darn happy. This however is just another phase of the evolution of a code junky.

# re: Using Regions in VS.NET

left by Prometheus at 8/8/2004 6:23 AM Gravatar
I use one region for the declarations, one region for constructors, another region for the properties, and then use a separate region for each method, if I got a sub-class I use another region for it with a bunch of sub-regions.

That way is the easiest IMO, that way when I need to fix or change something it's easy to find the method I need to work on since the whole page fits on the screen. Properties and declaration hardly ever need to be modified, same with the constructors and usually there's not more than a few.

# re: Using Regions in VS.NET

left by Lance Kind at 8/13/2007 1:57 PM Gravatar
I've worked with some developers who use regions to their detriment. They build methods that are multiple screens long and then rely on regions as an organization structure. The drawbacks?
* regions are just fancy comments. So it's still a really big functional block.
* regions don't scope variables. The really big functional block is sharing variables through the other regions.
* big functional blocks encourage spaghetti code. Since regions give some developers comfort that their code is clean (and it does appear to), it allows them to share those variables all through the functional block, which like spaghetti, makes it hard to later refactor into smaller functional units.

Until I started working with such individuals, I saw regions as a curio. But now I'm not so happy because the abuse of them leads to more work later on.

==>Lancer---
Title  
Name
Email (never displayed)
Url
Comments   
Please add 2 and 3 and type the answer here:
Copyright © Drew Robbins