#region is an antipattern or a code smell?

12

The #region of Visual Studio it hides the codes, everyone says that it is bad because it exists? Is it an antipattern or a code smell ?

    
asked by anonymous 25.08.2015 / 14:01

2 answers

9

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 the code that the programmer should move. They saw the error and created a better solution, partial . In this way you separate more adequately and securely.

If the classes are too large, she is probably doing too many things, she probably has a low cohesion . In the same way that methods should not have many rows because this indicates that it is doing too many things, a class should not be too large.

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

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

Grouping the field with property or event with delegate. It is also group by functionality. They should be close, but alone.

When organized by visibility may even be a little better but still shows that there are too many things. But when this is required,% w / w% may be a way out. Not everyone likes it.

But this feature itself does not improve the quality of the code or do 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 overkill.

It's not that you should not use it, it does not cause problems, but 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, you have moments to use. I usually 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 is used for collapsing code, so 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. Somewhere. I prefer to reduce the code or when it is not even possible, I separate what is API and what is implementation detail in separate files.

Already bad for grouping methods, it gets worse if you use within methods. Although I already think people often use white regions within methods. When you often skip blank lines to separate code parts of the method, regions are being created and they are probably not needed or indicate that the method is too large. 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. It was more of a hindrance than helping. I have already resigned because they required the use of this resource. I've learned to think better of code when I see need to use partial . And I see often. I'd rather avoid the short path.

This is part of the language specification . If it was just a feature of the IDE could use a comment. In the background the result is the same but the compiler has to deal with it.

    
25.08.2015 / 14:40
-2

#region is used to organize your code. In a class you have attributes, getters and setters, processing methods. Let's say you want to organize your class in regions to be better organized and you can find what you are looking for more easily. You can do 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, sorting their methods for example. So when you want to work with your methods, you can hide the other regions and work only with the method region.

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

    
25.08.2015 / 14:39