Regions can contribute creating and hiding code smells, decrease readability and maintainability.

Violated Single Responsibility Principle

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.

Legacy code

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

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.