Gerben van Loon

I don't agree. Using regions is actually very useful if you use it to hide all but the public interface of a class.

I recommend using regions to group members except for everything that is public. With tools such as ReSharper and Regionerate this is configurable and turns out to be actually very useful.

I beg to differ. Partial classes is something for generated code. And then regions are for grouping properties. While I would never use regions to group public with public and private with private I do use them for grouping properties by usage, for example in a Global.asax, to group routes for different parts of my website together.

And by the way: I expand regions by default. So no hiding for me :)

My opinion on this matter is that it isn't so much to do with regions as it is to do with bad coding practices. People who write bad code will write bad code no matter what restrictions you put on them.

As you say, regions don't eliminate complexity, they just hide it. Lack of regions will not solve the complex or bad code problem. The developer who hid the bad code in a region, will now just place it in plain sight. Having no regions will just make it easier to spot.

With this in mind, I wouldn't go so far as to discourage regions completely, but encourage their prudent use. In many cases, I place event handling code in a region because I usually don't want to see this, the public interface will be in another region.

@Kristof - I have another use for Partial Classes. I like to think of them as separation of responsibility/concerns. One such scenario is for implementing complex interfaces for a business object that have nothing to do with the business rules, but more with plumbing. I would write the interface code in a partial class so that those working on the business rules won't get distracted by this plumbing code. Of course, the usefulness of this is arguable but I find it rather useful, though I don't come across this problem often.