There seems to be a lot of negativity towards the #Region
in .net at the moment, with many people hating them and calling all usages of them ‘retarded’.
I can see their point, especially when you see the odd class with regions like this:
Class Foo
{
#Private Members
#Protected Members
#Friend Members
#Public Members
#Private Constructors
#Protected Constructors
#Friend Constructors
#Public Constructors
#Private Methods
#Protected Methods
#Friend Methods
#Public Methods
}
Clearly the person who wrote this was ill at the time (I hope…), and besides, where would Protected Friends
go? Hmm?
I however find regions useful, especially when writing objects (see what I did there?). Now while an object might have might be DRY and only have a Single Responsibility, it might also have many properties. What I tend to do with regions is hide my getters and setters:
Class Bar
{
Member1
...
Member2
#Region Properties
//....
#End Region
Method1(){/* */}
...
Method1(){/* */}
}
This way I am hiding standard boiler plate code, and everything that actually matters is visible. If you don’t like hiding properties that have a lot of code in them, then your problem may be the fact that you have lots of code in the properties. Something like PostSharp could allow you to inject all your properties with the common code such as PropertyChanging(sender, e)
, PropertyChanged(sender, e)
.
If you need lots of specific code in a property, then it is surely under unit test? If it isn’t, why not? And if it is, does it matter that you can’t see the property without clicking the little + sign?
One other slight point: with my method of #region
usage, if you don’t like regions, you have one click to expand it (or if you don’t like clicking, Ctrl+M, Ctrl+M
in VS will expand/collapse whatever is at the cursor position), so it really is not that difficult to cope with.
Like all technologies, use it when it makes sense. No Regions can be just as bad as many Regions.