#regions, huh! What are they good for?

I stumbled over a slightly different manifesto the other day. Or it was a legion actually. Developers taking up arms against a travesty of the C# language: #regions. You can read it at So what is the legion all about? Here’s the message from the website:

The Anti-#region Legion is a community for people who believe that the C# #region is an unfortunate part of the language.

I  saw this and thought I was behind it completely, but decided to revisit my previous experiences and assumptions on the matter before concluding.

The What

So, before we move on let’s dig a little into what #regions are. From MSDN:

#region lets you specify a block of code that you can expand or collapse when using the outlining feature of the Visual Studio Code Editor. In longer code files, it is convenient to be able to collapse or hide one or more regions so that you can focus on the part of the file that you are currently working on. 

So, basically it’s a way to group parts of your file into separate well-defined areas. Here’s an example of an expanded and collapsed region with the outlining feature

Example of an expanded and collapsed region

So, what’s the problem?

Richard Banks has done a good job of explaining his gripes with #region. Here are a few thoughts of mine as well.

Using regions to hide the complexities in a large class

By purposely hiding the code in collapsed regions, glancing and understanding what’s happening in a file becomes a lot harder. Some people argue that this is the perfect use of regions, since it gives a form of structure. I feel this is just a false sense of control, and hides the intention in the code. If you have hundreds of lines of code in a class then that’s a code-smell and you need to refactor, no amount of regions are going to help you.

I would prefer having to face that monster of a class on a daily basis just to experience the pain of trying to work in it. Bad code should hurt so much that you want to refactor it!

Using a partial class is an option to split up the code into multiple files, but I would argue that this is just attacking the tip of the iceberg. How many responsibilities does that class actually have?  Both the DRY-principle and the Single Responsibility Principle are crucial principles to follow to help you out of this mess.

Coding Standards – Defining class structure with regions

Coding standards are a great thing to have when working with other developers. There’s great value in opening up a file and feeling at home with the structure so that it helps focusing on understanding the code.

There are many developers that use regions as part of their coding standards like this:

Regions used to define the structure of a class

The result is a focus on sorting the visibility and types of members within the class.. I think this is also one of the default code cleanup settings in Resharper, which is a shame.

Whats going on?

Structure is fine and good, but what’s actually going on in this class? Exactly, it’s impossible to tell. You have to intentionally expand the regions to  figure that out. If this is how every file looks like, then you won’t be doing that actively. It’s directly in the way of continuously improving the code base.

If you could see the constructor and at the very least you would get the sense if this was a busy file with many responsibilities in need of refactoring or not.

False sense of content

Each of these regions may actually be empty. so you have to search for the code amongst all the region statements

Regions that lie

Do you see that region with private methods? If you look at the line-numbers you see that’s where all the logic lies. What if I told you that’s where most of all the public members were as well? Exactly, regions are like code-comments, they can lie about what they contain.

Is it all bad?

There are times when company policy forces the need to have license information  in the header of each source file. I guess this it’s alright to have regions at the top in these cases. I would prefer having this information in a file in the root of the project instead though.

There seems to be opinions in favor of regions from developers that work alone. So it’s a personal preference that doesn’t work well within teams. It’s also very common among inexperienced developers that haven’t learned all the tools needed to refactor.

I tried searching for proper usages for regions, but turned up more posts along the lines of this one. There may be actual good uses for them, and I’d love to hear about them. I just haven’t seen them yet.  So I stand here with the same conclusion as before I started writing: I won’t go so far as to force removing regions from the C# language, but I don’t personally see the need for them.

In regards to the legion itself, it’s a good, strong statement. Slightly crudely worded, but that’s what gets the point across, doesn’t it?

I would love to hear your thoughts on this matter. Feel free to drop off a comment or reach out to me.