I guess this is quite a dramatic blog title statement but unfortunately it is true. I am often cursing over regions I find in other peoples code. This blog post will tell you why generally I don't like them.

Both C# and VB.NET allows for a feature called regions. Regions at class level may look something like this:

Now, the benefit of using regions is that you may collapse them easily when you are not currently working with them. Many regions could then look like something like this

 Of course, in a real scenario, you would have a more real case choice of selecting regions as to group class members. I’ve seen that it is common to group methods and properties etc. according to member accessibility level, i.e. private, protected, internal etc. Also, it is quite common to group regions of common member functionality;  kind of like having inner classes but categorized as regions instead.

To make things worse, C# allows regions to be defined within members too:

So, how come I don’t like this? Well I have a couple of reasons for this:

1.       Regions at class level make the code harder to work with. I think most advanced (lazy ) .NET developers know that the Visual Studio short cut keys Ctrl + M + O collapses all methods and regions in a class. This action gives a quick and good overview of either the members or regions in the class. Even though you may expand/collapse a specific region with Ctrl M + M, it is quite a hassle to have to expand both regions and methods to get an overview of the actual code within the method. I think that an overview of the functionality of a class is best given by the natural language constructs themselves without using regions. Once you start adding regions to you code, you add an additional expand/collapse step in order to be able to start working with the actual code within you methods. This makes the code harder to work with.

2.       Often, when regions are used at class level, it is done because there are too many members in the class to keep track of. This means that the cohesion of this class is low which is bad. Another, very similar principle, founded by Robert C. Martin, is the Single Responsibility Principle. Regions tend to make you violate this principle since classes become too large and contain too much mixed functionality. More on this in a future blog post…

3.       Regions within methods share a common symptom. When regions are used within a method, it is likely done so because the method is very long. Too long if you ask me. Methods should be short and be easy to read and understand. Otherwise they will break what I usually call the Divide and Conquer principle.  In short Divide and Conquer in software design, as I choose to define it, is a major problem split into many smaller problems by decomposing a method into many smaller methods. This is how you understand and solve a major problem a lot easier since you don’t have to be keeping too much detailed information in your mind at the same time.

4.       When you use regions within a method, it is much more difficult to track the actual data flow between different regions. If local variables are used, and not state fields, you can easy see the API for each method. I.e. you see what input data each method needs and what output data it delivers. Regions within methods do not give you this and the code becomes much more difficult to understand.  

5.       Regions within large methods have another problem: if you receive an exception in operation and if you are logging the stack trace of the exception, you have a much more difficult time to track where the actual error occurred. With smaller methods instead, you will at least receive information in which method the error occurred. (…and of course you should not compile your code with the debug flag to true in operation environment…)

Well, these are the negative consequences of regions that I have come up with so far. Of all these negative aspects of regions, I think the potential violation of Single Responsibility and Divide and Conquer Principles are the worst ones. From what I’ve seen, regions tend to make programmers forget that they are developing in an Object Oriented language and instead program as if using a functional programming language. Sure, functional programming languages have their strengths, but improved readability and therefore better maintainability is not one of them.

So. Is there a place when regions actually are ok to use? Well, if someone has placed a region to group some less significant members of a class, I might accept it although I probably would not define the region myself. However, I will never ever accept regions within methods since I think this violates the principle of Divide and Conquer.

Though, I have found one case when I actually use regions myself. I find them excellent to use when I am constructing demos for course material. Regions let me hide code and comments that I don’t want my students to see yet. Alas, I use regions strictly for educational  purpose. Wouldn’t the world be a better if everything just was a big nice demo…. However, it is not. So lay off those regions in your code. Please.