Support for regions (SA1201 + SA1202)

Apr 7, 2011 at 10:55 AM
Edited Apr 7, 2011 at 10:57 AM

We often use regions to group our code in logical sections.

The problem ist, that the rules

SA1201: ElementsMustAppearInTheCorrectOrder

SA1202: ElementsMustBeOrderedByAccess

are often violated, because of our regions.

The rules should recognize regions and check the order IN the regions.

e.g.

#region Part1


  public void Func1()
  {
 
  }
 
  private void Func1()
  {
 
  }

#endregion

 

#region Part2 

  public void Func2()
  {
 
  }
 
  private void Func2()
  {
 
  }

#endregion

Coordinator
Apr 7, 2011 at 3:00 PM

I would propose almost the opposite. Don't use regions at all except to group private methods, constructors, public properties, etc. so groups of the same type of element. If you're grouping code this way then the type may be too big. Use partial types to achieve the same result.

Developer
Apr 8, 2011 at 3:47 AM

I agree with Andy.  The ordering rules help enforce a sense of "where to find things" better than regions.  Further, having a single code file big enough to require regions can be a flag suggesting maybe the Single Responsibility Principle is being violaged.  Also, from what I've heard, regions are pretty much redundant in newer dev environments where the user can essentially lay out similar mechanisms for themselves which don't clutter the actual source file.

Apr 8, 2011 at 2:25 PM

In C# 1.0 I used regions to group interface implementations (pretty much like VS generates interface implementations), base class overrides.

With partial classe files I tend to separate those into separate files.

Nevertheless, for some people makes sense to group by cuntionality like backing field, property, property changed event and property changed event firer.

Apr 8, 2011 at 4:29 PM

With automatic propterties, the need for grouping has diminished. I agree with Andy.

Apr 10, 2012 at 10:06 PM
Edited Apr 10, 2012 at 10:11 PM

I disagree. Automatic properties sure may have helped.

Have you ever written an application using the MVVM framework?

A property that uses MVVM is 9 lines.  So if such properties are separated by a space, you now need 10 lines. 

public String FirstName
{
    get { return _FirstName; }
    set
    {
        _FirstName= value;
        NotifyPropertyChanged("FirstName");
    }
} private String _FirstName;

public String LastName
{
    get { return _LastName; }
    set
    {
        _LastName= value;
        NotifyPropertyChanged("LastName");
    }
} private String _LastName;

 And an ICommand is a property too and has a function attached that is at least four lines.

public ICommand ButtonClickCommand
{
    get { return _ButtonClickCommand ?? (_ButtonClickCommand == new RelayCommand(f = HandleClick())); }
    set
    {
        _ButtonClickCommand= value;
        NotifyPropertyChanged("ButtonClickCommand");
    }
} private String _ButtonClickCommand;

private void HandleClick()
{
    otherobject.dowork();
}

So a well-written ViewModel with 5 properties and 2 ICommands will be at least 78 lines. Having a separate region for Properties, ICommand Properties, and Methods is quite nice.

 

#region Constructor(s)

#endregion

#region Properties

#endregion


#region ICommands

#endregion

#region Methods

#endregion

With the ViewModel portion of MVVM at least, the need for grouping has not diminished, but has increased.

Oct 29, 2012 at 4:09 PM

I've just started using stylecop and am frustrated for the same reason.

I prefer interface implementations to be in their own regions.  It's the only time I use regions.

I'd like the ordering rules to be applied separated within these regions.

Dec 3, 2012 at 7:35 PM
Edited Dec 3, 2012 at 7:36 PM

I use the following regions snippet always and remove unused regions. This validates against SA1201: ElementsMustAppearInTheCorrectOrder.

 

#region Constants

// Constants here.

#endregion Constants

#region Fields

// Fields here.

#endregion Fields

#region Constructors

// Constructors here.

#endregion Constructors

#region Properties

// Properties here.

#region Dependencies

// Dependency properties here.

#endregion Dependencies

#endregion Properties

#region Methods

// Methods here.

#region Actions

// Action methods here (MVC).

#endregion Actions

#endregion Methods