28

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?

Yanhua
  • 541
  • 5
  • 9

7 Answers7

20

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.

Pang
  • 9,564
  • 146
  • 81
  • 122
Nick Craver
  • 623,446
  • 136
  • 1,297
  • 1,155
  • 4
    Isn't that backwards? They are the ones that *wrote* it, somebody as yet unnamed has to read it. And regions *definitely* make that awkward. My personal preference is to hate them when I have to read code. – Hans Passant Mar 12 '10 at 03:13
  • 4
    @nobugz - Currently, they're the ones dealing with it every day, going back over for bug fixing, etc...I'd still say they're reading it more than anyone else. Overall I consider it minor issue anyway, as you could string out all regions with a quick regex in no-time if needed. That and Ctrl+M+L makes it so I can use or ignore them pretty easy, but probably personal preference there. – Nick Craver Mar 12 '10 at 03:24
  • Well, I'm not that interested in reading buggy code. Surely SA1124 is a reminder. The point of a style cop is to *avoid* personal preference affecting the product. – Hans Passant Mar 12 '10 at 03:33
  • @nobugz - True, but then again, why was a feature added to only say it can't ever be used by the rules engine? Obviously there is some usefulness to some set of developers if it was added at all...seems to be a contradiction on StyleCop's part to me – Nick Craver Mar 12 '10 at 03:52
  • 1
    Or on the editor. I'll rephrase my previous comment to "affect the finished product". – Hans Passant Mar 12 '10 at 04:03
  • 2
    I agree that using region or not is an agreement inside team. Microsoft CAB project uses it, but Microsoft Enterprise Library 5 don't use it. I think most existed C# project are using region, because it sounds like a good grammar feature of C#. Using it, and avoid to be abused is a my preference. – Yanhua Mar 12 '10 at 06:19
  • 2
    StyleCop rules can be changed, right? Obviously they are not the universal rule (regions fan here) – Stilgar Apr 10 '12 at 21:12
  • Regions don't make code awkward to read at all. Most the time they make the code clearer by having the region. – Rhyous May 22 '15 at 15:13
  • 1
    I completely agree with @Rhyous. Regions can be a good thing and can make code easier to read. And, I value and understand that others don't have this same experience. That is why this is setting (on/off) and not a hard/fast dictated rule, or even something that when used won't compile. It's entirely a preference thing. I hate when someone takes a dogmatic view at things like this. Obviously, part the world like it and part of the world doesn't. Doesn't make regions bad or wrong. In fact, that's probably why MS included them in the language spec. They can be used when appropriate. Rant over. – Steve Kennedy Oct 15 '15 at 17:26
17

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.

mheyman
  • 4,211
  • 37
  • 34
  • 4
    To complement this answer, I'd note that to separate machine generated code in a separate file, one would use `partial` classes. – Suzanne Soy May 23 '13 at 20:02
  • 1
    +1 It seems every time I encounter regions when reading someone else's code I think it would have been better if they instead channeled their OCD tendency into something more architecturally productive such as Extract Class and what not. That's what I do! – BrandonLWhite Oct 12 '15 at 22:05
10

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.

Rhyous
  • 6,510
  • 2
  • 44
  • 50
8

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.

John Saunders
  • 160,644
  • 26
  • 247
  • 397
  • 1
    Abused on using region can make browsing code unfriendly. In my practice, I don't use any nest region and only region Fields, Properties, Constructor, Interface implementation, Public methods, Private and Help methods. – Yanhua Mar 12 '10 at 06:18
3

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.

Michal T
  • 814
  • 8
  • 5
3

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.

vargonian
  • 3,064
  • 3
  • 27
  • 36
3

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)

hfrmobile
  • 1,213
  • 16
  • 16