This project is read-only.

Use of #Region in code - guidance?

Topics: Business Logic Layer
Oct 27, 2011 at 4:02 PM

Ben, Rtur or others,

Many (most?) of the code files have various regions marked off with #region.  Typical regions are "Constants and Fields" , "Properties", "Events", "Implemented Interfaces", "Public Methods' and "Methods".

How committed is the team to maintainining this in the code?  Do the current main developers for BE.Net like it?  Does new code need to use this approach? 

I ask, because I find that the first thing I do when I go into a new file is ctl+M ctl+L to cause visual studio to expand all of these.  This isn't hard for me to do, so it's not a big deal, but I'd prefer if most all the code were visible from the get go.  I can see using them for properties and Implemented Interfaces, maybe, but beyond that, I'd prefer if the code wasn't chunked up into so many regions. 

Another reason, I prefer less  #region use is that it forces code to be seperated from it's logical order in some cases.  For example  when creating a control that inherits from System.Web.UI.Control one may want to override OnLoad and RenderControl.  The RenderControl method ends up occuring in the source code before the OnLoad method because RenderControl is a public method in the base class and goes in the "Public Methods" region and OnLoad is a protected method in the base class and goes in the "Methods" region.  When reading the code from top to bottom it'd be nice to have OnLoad occur before RenderControl.  Also, it's not uncommon for a public method to call several private "support" methods to help it do it's work.  From a code readability standpoint, it can be really nice to have those support methods right under the public method.  Doing so isn't possible though if methods are sorted into "Public Methods" and "Methods" regions.

That's why I was wondering what the current thinking was about the use of #region in the code?  Thoughts?



Oct 27, 2011 at 5:18 PM

There is no formal restrictions on using regions. Current practice is inherited from original code base and preserved for consistency, it's confusing dealing with different styles in the same application. I think regions are double-edged sword - they help organize large classes into manageable blocks instead of organizing code into manageable classes. So best would be refactor and restructure but that would be large task on it's own and also risky with no benefit for end users. I'd say, new code can be written so that it does not need regions at all. But old code either preserve things the way they are or present better solution but only if it can be implemented throughout entire application. Obviously, that's just my personal opinion.

Oct 27, 2011 at 7:05 PM

Thank rtur.  I understand the tension that can exist between maintaining existing coding style and introducing new approaches.  When you create a new class BE do you tend to the the full array of regions?  What I'm really asking I guess is what should I do for the Related Posts Widget project I'm working on?  (contains two new classes and a heavily overhauled class)