Are #regions evil?

Are #regions evil? The answer is Yes and No.

Like everything else, using at the wrong place or for the wrong reason can be detrimental. After all, the wrong person behind the wheels can make a car deadly-weapon.

The common complaint for using #regions is it promotes bad code. Consider the following example:

Most developers would agree that the above usage of the #regions create large monolith methods that is only separated by regions, thus creating unmaintainable code.

Another complaint is that #regions were introduced by Visual Studio for hiding auto-generated code, thus only auto-generators should use the #regions.

Related complaint for #regions is that it "hide code" unnecessarily. For example, when a quick-scanning through a code-file, one needs to use the mouse to expand the regions to see the code in full.

However, expanding / collapsing code is not an exclusive feature of #regions; namespaces, classes, enums, methods and other "code blocks" are already collapsible / expandable by default in Visual Studio. Regions just allows the developer to add a label.

Furthermore, one could easily collapse / expand all regions using following keyboard shortcut in Visual Studio:

To expand all collapsed regions and methods:

Ctrl + M + L

To collapse to definitions:

Ctrl + M + O

So should you as a developer use regions?

I would personally use it to "group" related methods in a class to reduce noise in code.

It would a akin to surgeons operating on a patient with a cover that only have a "cut section" so that they can focus only on the part that they are operating on:

For example, I would use a region to group all constructors overloads.

The similar groupings can be done for all Public Methods, Private Methods, Overridden Methods and so on.

One can also group smaller breakdown methods of a "main" method and group them logically together:

I would however, not use regions inside of a method such as this:

In a case of this, I would usually extract the regions out into it's own methods and call them from the "main" method.

By extracting into smaller methods (or "units") also helps writing better unit-test coverage.

Some might argues that instead of grouping related methods, they should also be extracted to it's own classes.

One can be either end of an extreme; too many regions, or too many methods / classes; both creates poor maintainability of code, which is what we as developers are trying to avoid.

I chose the middle ground; use regions using your professional developer judgement, not by default.

Also #regions can sometimes be useful as a "temporary measure" when refactoring legacy code, to understand the existing code's control of flow better.