I know that lots of people hate #regions in C#. IMO there is at least one legitimate use of them:

Sometimes I have a class which, in addition to its core functionality, needs to implement a commonly used interface such as IEquatable or IEnumerable. This interface requires several members which are quite separate from the main functionality of the class and usually very "generic" in their implementation.

The usual argument against regions is that you should refactor instead. In a case like this, it doesn't make sense to refactor.

In this case I think it makes sense to group these members in a #region.

Do you agree? Why or why not?

  • There's a development-team downside to using #region blocks: some less-experienced people don't know they're a thing. They have a harder than necessary time finding code when it needs maintenance.
    – O. Jones
    Oct 16, 2020 at 11:51

2 Answers 2


I know that lots of people hate #regions in C#

Whenever #region gets mentioned, people immediately jump on the bad practice bandwagon. And it's true that #region can be abused to hide monolithic code.

But your suggested approach isn't monolithic, and it's actually what #region was designed for: neatly organizing code that belongs together (in the same class) but doesn't generally get addressed together during development.

I would point out that if the size of the class gets longer (but not monolithic), you could reconsider #region and move towards partial classes instead. But for your current question, that's not really relevant just yet.

So yes, I agree that #region both has valid use cases, and that yours is one of them.

  • What do you mean with monolithic code in a single class? I personally only know the term in relation to entire applications.
    – Rik D
    Oct 16, 2020 at 10:07
  • @RikD: A monolith is just another word for a "big chunk", from the Greek for "one stone". Just like how an application can be one undivided code block that should've been broken down into pieces, a class can be a large chunk that should've been divided into pieces. It's a matter of scope/scale, but the same principle at play :)
    – Flater
    Oct 16, 2020 at 10:16

As with other code style issues, this is subjective and hard to make good universal claims. IEquatable had far fewer members and doesn't muddy readability as much as IEnumerable, for instance, but specifically for IEnumerable I would usually recommend against implementing it at all and instead expose a property. Unless, that is, you're actually implementing a collection type, in which case, isn't the interface a "real" part of your business logic?

#region is a tool. Like many, it can be abused and the code made less readable, but when used properly (and sparingly) it can help readability. One place it can certainly be useful is hiding boilerplate code, and a lot of times implementations of framework interfaces (like IEquatable or IEnumerable) certainly count as boilerplate. But I think that's not a good criterion for "when should I use #region" because a better solution for boilerplate is eliminating it, not hiding it.

You can't eliminate all boilerplate, that's the way it is, but before hiding a piece of boilerplate code with a #region, ask yourself if you actually need this implemented here. Do you need to implement IEnumerable, or does it make more sense to simply expose your inner collection as an IEnumerable property? Do you really need to implement IEquatable on the type itself, or do can you create a separate IEqualityComparer<MyType> implementation?

  • I don't understand your last paragraph. Could you please explain your point there again? Oct 16, 2020 at 10:27
  • Expanded and clarified last paragraph. Oct 16, 2020 at 10:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.