Regional Conflicts

We have all come to love our IDE features and take them for granted nowadays. Features like intellisense, code-complete, refactoring and code organization and of course the use of Regions.

The #region and #endregion keywords basically provide the ability to hide code and collapse it into a short word or phrase provided at the beginning of the block with the IDE showing a plus sign to expand and collapse the region.

Eg: #region Public Methods

#endregion

While regions are handy and have become popular, I use them myself occasionally. I don’t particularly fancy them, neither do they improve my code’s readability by much. I believe in keeping my code concise, using descriptive names for methods, classes, variables, etc. and keeping my classes short and easy to read. But sometimes a region for collapsing those using statements and grouping similar methods like constructors, private variables and properties, disposing, etc comes handy.

As regions help you “hide” your code some developers like to abuse it to hide shameful code.

Let me share with you an example I saw recently. Here the developer is mapping data from his objects to an external system based on keys. The code for this method went of for a few hundred lines of code having a mapping for every field the external system needed.

This clearly shows that the developer is trying to write separate methods for mapping different pieces of data but instead choose to shove all the code in a switch case statement broken up into different regions for each specific piece of information. It may look organized but in reality it’s a poorly designed function that has been “regionized” to look readable. A classic case of hiding your dirty laundry in the closet.

Another strange use of regions I have seen over the years since regions have been around is the use of regions as grouping methods as if they were writing classes. This is a classic example from my procedural programmer friends who really have not gotten on the Object Oriented boat that left the shore a long time ago!

Here is an example:

publicclass DataAccess { #region Account Data

public InsertAccount(Account account) { }

public DeleteAccount(long accountId) { ... }

public UpdateAccount(Account account) { ... }

#endregion

#region Order Data

public InsertOrder(Order order) { ... }

public DeleteOrder(long orderId) { ... }

public UpdateOrder(Order order) { ... }

#endregion

... you get the point ... }

A class like this went on for the few hundred objects in the system that needed to be persisted and was no less than 10,000 lines of code! The developer boasted the code to his colleagues and marveled at it. I remember working on this code file. It was so big that even the intellisense started to choke up. When I typed ‘this’ and hit the period key it caused the machine to run on overdrive for a few seconds before the list showed up! Now that is some serious regioning!

I don't want to give directions on how to use regions but I will say that if you design your code well and make sure your program functionality is broken down in to understandable, re-usable and maintainable classes you will find that your code does not need to be regionalized much. Short concise classes broken down into short descriptive methods will take you far in keeping your code organized and readable. By default the IDE makes methods, classes, and namespaces into regions and that should be enough for the majority of the code you will write!