Craftsmanship

#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  http://anti-region-legion.org. 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-expanded-collapsed.png
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:

example-regions-as-structure.png
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.

  • Pingback: Blogged: #regions, huh! What are they good for? - pavsaund.com()

  • This is one of the C# features I’ve always wrestled with. Back as a noob many years ago, I used them to define class structure as you wrote. Now, I think twice before using them.

    In the current project I’m on, I’ve used them to group VM properties. I know it’s a code smell. But I rather use a #region than start an internal discussion on why the VM should be broken into separate VMs. It works, why fix it mentality /sad panda

    TL;DR: I used #region to group VM properties.

    • Feeling familiarity when moving throughout a code-base is really good. And structure acts a visual aid to help navigate. Reducing the mental noise.

      Have you tried StyleCop as an alternative for achieving structure? We’ve used this to give the needed structure and serves as an automatic compile-time check. Not to confuse this with good coding practices and aligning a team, but a nice start. Also works well if you use ReSharper.

      • StyleCop reminds me of FxCop. It will be a tough sell for the team, but I can sure incorporate it in my local environment. Thanks for the suggestion.

        • cool, let me know how it goes 🙂

          Also, it’s possible to incorporate stylecop for only a specific project (and maybe also specific folder…I have to double check that). So you can actually have it run on your production code.

          Maybe I should try to do a blogpost on that.

          • A blogpost on that would be awesome to have for reference.

  • Pingback: Empathy: an essential skill in Software Development - Coding with Empathy()

  • Rune Andreas Grimstad

    There is one good use case for #regions in my opinion, and that is to mark/hide generated code. In most cases you will do this with partial classes, but in the cases where you can’t do this then #region is useful.

    • Thanks for dropping by @runeandreasgrimstad:disqus!

      So if I understand you correctly, there are cases when code has to be there because of a framework / library generates it, which you don’t care about it, but it has to be there.
      If you can avoid being in the classes / files that are generated, then I guess it doesn’t really matter, but if you are forced to amend code within those classes, then I see that #regions may be useful.

      I would consider trying to avoid those files altogether, but I guess you have no choice sometimes.

      Thanks for sharing!