#Region is an antipattern or a Smell code?

Question

The #region from Visual Studio he hides the codes, everyone says he’s bad, because he exists? It’s a antipattern or a code Smell?

Answer 1

Yes, it is. It shows that the code is too big, too difficult to organize.

It exists because they need to separate code generated by the IDE (Visual Studio) from code the programmer should mess with. They realized the mistake and created a better solution, the partial, this way you separate it more properly and safely, prefer it.

If the classes are too big she’s probably doing too much stuff, she probably has low cohesion. In the same way that methods should not have many lines because this indicates that he is doing too much, a class should also not be so large.

Most of the time when people organize by functionality clearly shows that the class has too many functions.

Grouping forms

Some group the implementation of an interface, which often only has one member (then it is ridiculous to use #region but people use it for consistency). Even when there are multiple members, there is no gain. It’s still a grouping by functionality.

There is the field grouping with property or event with delegate. It is also grouping by functionality. They must be close, but only.

When organized by visibility may be a little better but still shows that there are too many things. But when this is necessary, in general the partial can be a way out. Not everyone likes.

Abuse-free

But this feature itself neither improves the quality of the code nor does anything additional. It solves a problem caused by the code itself that makes it difficult to read the code.

Grouping code is valid, delimiting where they are is exaggeration.

It’s not that you shouldn’t use it, it doesn’t cause problems, but it’s that its use indicates something wrong in your code that you’re trying to solve with it. It is tempting to do wrong because there is a "solution".

Like everything else, you have moments to use. I often say that it is something that should not be in the language because deep down it is a facilitator for the IDE, even when it serves to collapse code, then in this case a comment is sufficient, although probably used to solve such a very large code problem.

But if you ask me where I use it: nowhere. I prefer to reduce the code or when it is not even possible, separate what is API and what is implementation detail into separate files.

It is bad enough to group methods, it is worse to use within methods. Although I already think people use religions white within methods. When it is customary to skip blank lines to separate parts of code from the method, it is creating regions and probably they are not necessary or indicate that the method is too big, but it seems to be a taste of most people.

Stylecop SA1124: you should not use Regions

My personal experience of opening and closing the regions was terrible, more disturbing than helping. I have already resigned because they demanded the use of this resource (okay, it was not the only reason). I have learned to think better of the code when I see need to use #region. And I see often. I prefer to avoid the shortest path.

It is part of the language specification. If it was just a resource in the IDE you could use a comment. At the bottom the result is the same but the compiler has to handle this.

Answer 2

The #Region is used to organize your code. In a class you have attributes, getters and setters, processing methods. Suppose you want to organize your class in regions to get better organized and you can find what you’re looking for more easily. You can do it like this:

public class MyClass 
{
    #region atributos
    //aqui voce coloca os atributos
    #endregion

    #region metodos
    //aqui você coloca seus métodos
    #endregion

    #region getSet
    //getters and setters
    #endregion
}

Or even more divisions, classifying their methods for example. So when you want to work with your methods, you can hide the other regions and work only with the methods region.

It’s a way to organize your code to be more readable, organized and easy to develop.