c# #region Tags and Why I Don’t Like Them

I’m back to the Microsoft stack (ASP.NET MVC, c#, etc.) for the first time in a while. One of the things When I worked with it previously, I hated #region markers in any code file. Now, since I’m the lead, I have a policy of deleting them where I find them. No exceptions. I did tell my team that I would do this but I never really explained why.

The #region was originally used to segregate generated code from the code written by the developer. These days are over, partial classes totally eliminated this usage.

Today, I see two main uses of #region tags.

First, they are used to group types of things. Region tags are put around:

  • Properties
  • Public Methods
  • Private Methods

The second common usage is grouping related things:

  • Around an event and it’s delegate
  • All methods related that talk to the database

So why don’t I like #region markers?

Regions Hide Code

When a class is opened in Visual Studio, and it has #region tags, the #region tags are collapsed by default. In other words, at least some of the implementation of the class is hidden when the class is opened. This can make it difficult to find what you were looking for. And, expanding the regions can take you out of your train of thought by preventing you from going straight to what you were looking for.

Regions Hide Size

One of the more common design problems is a class that does too much. The feedback from scrolling and navigating a large class is one of the items that helps determine it is time for a refactor. Regions eliminate this feedback, they can make a class that is way too large not feel that way. But that feeling is an illusion, as soon as any serious work needs to be done, the size of the class will quickly become an obstacle to maintaining the class.

Regions Hide Complexity

The hidden code can also hide complexity. If a class is doing too much, when it’s responsibilities are muddled, regions can be used to group that functionality to make things appear more maintainable. But again, it is an illusion. Because as soon as something not insignificant needs to change, especially if that change will cross regions, the region approach will make the change more difficult.

Let’s Make Maintainable Code

One of our goals when developing most systems should be delivering maintainable code. Regions work against this.

Microsoft has acknowledged that #region tags should not be used any longer. Today, the default settings for StyleCode, do not allow #region tags to be used. In other words, Microsoft no longer believes #region tags need to be used. So neither should you.

>c# and Brackets

>c# uses a lot of brackets. But there are times when you don’t need brackets; specifically when you only have one statement to execute in the loop/if statement. You have to use brackets when you have multiple statements inside the loop/if.

I do think though, there are times when you should use brackets even though the language doesn’t explicitly call for them.

Specifically, when I have nested loops/if statements, I use brackets on all but the innermost structure even though these aren’t required. The c# language reference for if-else uses the following example:

int x = 12;
int y = 18;

if (x > 10)
if (y > 20)
Console.Write("Statement_1");
else
Console.Write("Statement_2");

I would never write that; I would automatically add brackets around the outermost if:
int x = 12;
int y = 18;

if (x > 10)

{
if (y > 20)
Console.Write("Statement_1");
else
Console.Write("Statement_2");
}

Why? I think the first structure is more error-prone. Also, the simple addition or removal of an else can imply one thing while another thing is happening. For example, what if the first block was rewritten this way:

int x = 12;
int y = 18;

if (x > 10)
if (y > 20)
Console.Write("Statement_1");
else
Console.Write("Statement_2");

This makes it appear that the else is associated with the first if statement but we know it’s not. Visual Studio’s automatic formatting should fix the formatting eventually. But until it does, the visual appearance doesn’t reflect how the code runs. And that can cause bugs that are hard to find. So I will continue to always put in the brackets because there is nothing worse than bugs that can hide in plain site.