BP158: Avoid #region in your code wherever possible
Regions can contribute creating and hiding code smells, decrease readability and maintainability.
Violated Single Responsibility Principle
Some people say that regions make the code nicely structured.
We don't think so. We have seen too many times that people started to use regions when the class was too long, unreadable, without clearly defined purpose.
So when you think you need to use regions, think if you can simplify the class instead. Break it down to multiple pieces. Extract some logic to the other files.
99% cases it is what you should do instead of using #region.
One more click
The feeling when you click every file and then you need to do many more clicks to expand private fields, public properties, constructors.
Why would one want to do that?The less clicks you do, the faster you are.
Do not make the access to your code more difficult for the other readers. Be proud of your code, show it.
Regions hide code and introduce unwanted surprises
There are developers who write messy code and then hide it to the collapsed region. Everything looks nice and sweet. And then you expand the region and bang. You wanna cry.
Keep the code readable. Be transparent. Don't hide code to regions.
If the code is visible, there is higher chance that someone will refactor it.
If the code is hidden, there is a chance that someone will miss it and bugs will be introduced to the system.
The deadlines might also be affected because developers could be thinking that the code has 150 lines and estimate the effort with the assumption of low complexity just to later realize that there are 2 regions containing additional 1500 lines.
No regions inside a method
Don't use regions inside a method. Instead, extract the block to a separate method. Methods should be short and readable and it should do one thing.
If you need regions inside a method, it is an evidence that your method does more than one thing.
Don't group by member type, accessibility or visibility
You shouldn't use regions to group by fields, properties, constructors, public or private methods.
Your team should have coding standards defined and everyone on the team should know what is the preferred order of class members. If that is not the case, define coding standards with your team and communicate it frequently. But don't take this as a reason for using regions.
Don't hide argument validation to a region
If you have many validations at the beginning of the method, extract the validation logic to a separate method or leave the validation and extract the rest of the method to a separate method.
You should avoid #region wherever possible but in some cases you mind find yourself in a situation where adding a #region might be helpful. Always think about it - this is an emergency solution. Patch. Hack. Could you refactor? Could you extract the block? Do it.
Are you really in a state of emergency and do you really need the #region and there is no other good way around? Then use it. (You will pay for it later.)
Too long LINQ and SQL queries
If you see LINQ queries that are having tens of lines, extract them to extension methods or to standalone methods. The same applies to too long SQL queries (raw SQL statements) if you can't use stored procedures.
"But I need regions..."
If you need regions, it means your code is very likely bad. It's not that you need regions. You need refactor.
StyleCop rule SA1124
What we heard and what we answered
How about you?
Do you like regions? Tell us why.
Do you want to kill yourself when you see a #region? Comment on what are the reasons.