#endregion

There has been some talk lately about regions and whether they are good or bad. I have finally loosed the shackles of regions once and for all. Yes, my code was once rife with what I thought were well organized regions of thought and code, but therein lies the problem. It is very seductive to become ensnared in the warm embrace and the illusion of organization that regions provide. In reality, regions hide code and this opens up the door for a crazy glue sniffing code fairy to sneak into your house. The next thing you know, there's money missing off the dresser, and your daughter's knocked up. I seen it a hundred times…but I digress.

If you feel compelled to wrap your code in a region, ask yourself why. Are your methods getting too long to read without paging? Does the class have so many properties that you spend more time scrolling than writing code? Are you using them to “clean up” the code? All of these are indications that the code is need of refactoring, or at the very least re-evaluation.

If your code is grouped within nice neat region packaging, you are probably ready to take the next step and move those regions into their own classes. Do not forget the Single Responsibility Principle is our friend. Regions also increase the likelihood that code that needs to be changed, refactored, moved, or deleted will get missed.

Removing regions also goes a long way to increasing code readability. One thing we should strive for is writing code in such a way that it communicates more effectively with other developers.

Regions are often the rug under which ugliness gets swept. It is time to release the dust bunnies and clean up your code.