Jim,
As a number of others have said. Bad use of a region does not make it bad.
Like the others I use it to group code. These groupings tend to include:
- Patterns - all the members for a pattern are in their own region. Seeing
the title of the region indicates to me the class implements that pattern
- Interfaces - all the members implementing an interface are in their own
region. For larger interfaces I will create a number of region groups
- Concepts - I'll create a region for overrides & interfaces that share a
concept. Comparability for example. The IComparable interface & the Equals
override I'll group together in a single region. Formatting is another
concept I will group.
- Static members - If the class has shared/static members that support the
class, as oppose to the intent of the class, I will group them in a region.
Most regions I place at the end of the class, Pattern & static regions tend
to be at the top of the class.
Rarely will I nest a region inside another region. And especially rarely
will all the code in a class be in region. I like to see the 'important'
members outside of a region, I put the less important 'support' members
inside of regions.
Hope this helps
Jay
"Jim" <ssss> wrote in message news:uj*************@TK2MSFTNGP10.phx.gbl...
Are #region a bad thing or are they good?
As far as I see it #region's are a bad thing as they let lazy programmmers
have large and bloated methods divided into regions that then appear as
small methods, they also show bad analsys and design when used in this
way......
Thoughts?
Cheers
Jim