StyleCop SA1124 DoNotUseRegions is reasonable? [closed]

As it currently stands, this question is not a good fi开发者_如何学Pythont for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 9 years ago.

SA1124 DoNotUseRegions suggest that region should not be used anywhere. Is it really reasonable?

I think region is a way to group relative code together and make large class easy to read, for example, if you generate interface method for a class in vs2008 via context menu, a region will be automatically inserted.

I would like to remove this rule while checking code style. May I know your opinions on this rule?

---

This is going to be a personal preference thing. The only thing that matters here is what you and your team prefer. Forget what StyleCop says, you're the ones reading it, you're the ones maintaining it, whether with or without regions works better for you, that's all that matters.

If you're releasing it as an open-source project...and this is my opinion here, I think the same applies. Use whatever the core team is more comfortable with. If you get a lot more team members aboard and more contribute, re-visit the issue later, this can always be changed.

---

There is no more need for regions in well written code. It once was useful to hide machine generated code. Now that code goes in a separate file. Regions can still be used to hide poorly written code.

---

I like regions and my team and I feel code is more readable with them.

Here are the times when I love them...

If you have a company standard to write unit tests with Arrange Act Assert (AAA) then you could require unit tests to look as follows

[test]
public void MyFunction_Test
{
#region Arrange
#endregion    

#region Act
#endregion

#region Assert
#endregion
}

I really like this format especially when there are clear separations and doing so inspires others to do something correctly, such as write unit tests correctly.

The other place I like region is code is when you know you are going to delete the code soon.

#region Drop this region next version when we drop 2003 support
public void DoSomeThingWithWindowsServer2003()
{
   // code the is for Windows 2003 only
} 
#endregion

I also use regions to separate the different parts of my classes even if the class is very small.

#region Constructors
#endregion

#region Properties
#endregion

#region Events
#endregion

#region Methods
#endregion

#region Enums
#endregion

Usually a class won't have all of these (if it does you may wonder if you are doing too much in a single class) but I think if you are looking for a single method or property, it is nice to have a single place to look. Not to mention a Property in a ViewModel (MVVM anybody?) using INotifyPropertyChanged is 10 lines (9 lines plus a space), so well-designed and well-written ViewModel object with only 5 properties, means the properties section is at least 50 lines of code.

I also especially like them when using someone else's poorly written code. It is silly to assume you can always refactor to use a perfect design. For example, you have a class with 2500 lines or more. Sure this probably could have been written better but you didn't do it, it works, and it is tested and your business has the code in "fix only" lockdown so refactoring isn't allowed. You can make an overly large class (poorly written or not) much more readable using #region statements. You get a lot of the readability benefits of separation of concerns without actually separating the class and then once the code comes out of lock down and you can refactor, the majority of the separation work may already be done using #regions and you can convert your regions into separate class.

---

I think that regions can be abused, but they are a useful technique for allowing a reader to focus on certain areas of the code at a time.

I would avoid too many levels of nesting, however.

---

In my opinion there is one exception where a #region/#endregion makes sense: When implementing Interfaces!

e.g.

#region Implementation of IDisposable
public void Dispose()
{
  // implementation here ...
}
#endregion

In all other cases you should not use #region as they're obsolete (I assume the where created for hiding generated code - .net-1.0 and .net-1.1 but now there are partial classes for that)

---

I wonder if this rule is a side-effect of other more generally accepted rules, such as ordering of private/protected/public members. Following these ordering rules would necessarily break the logical grouping of #regions in many cases, so they'd become mutually exclusive.

---

From my experience they should not be used at all. Junior developers tend to abuse them and create overly complex classes whose complexity is "smartly" hidden behind numerous regions.