Regions == Evil

I had an email thread at work with a bunch of the guys on regions and this is the concensus we generally have come to (some of the statements are theirs, not mine, just paraphrased here). I was once a convert who liked regions. I enjoyed them. They made me happy. In all the code I would do something like this:

class UserCondition : IActionCondition

{

    #region Fields

 

    private int _condition;

 

    #endregion

 

    #region Constructors

 

    public UserCondition(int _condition)

    {

        this._condition = _condition;

    }

 

    #endregion

 

    #region Properties

 

    public int Condition

    {

        get { return _condition; }

        set { _condition = value; }

    }

 

    #endregion

 

    #region Public Methods

 

    public bool CanExecute(string action, WorkItem context, object caller, object target)

    {

        string userName = Thread.CurrentPrincipal.Identity.Name;

        return userName.ToLower().Equals("domain\\joeuser");

    }

 

    #endregion

}

That felt good and organized and neat (almost in an OCD way).

However I have seen the errors of my ways, as others have before me. Regions are evil. Pure and simple. The absolute incarnate concentrated type of evil that only the Time Bandits would fear and not the watered down, garden variety kind of evil.

They're great for hiding the annoying details of an IConvertible implementation or designer generated code (when it's not already in a partial class). But I often create methods on the fly using ReSharper and it is not going to look for the correct region to place the method. So having everything separated into regions actually slows me down because I have to find where to put the method.

ReSharper is your friend. Ctrl+F12 is all you need to find stuff in a file. Using ReSharper's type member layout to enforce code layout in a file, you can get consistency across all teams so one code file isn't vastly differently organized (say that 3 times fast) than any other project. With the custom pattern on, formatting puts all the members in all the right places and keeps layout and code style somewhat consistent across teams. It makes diff comparisons and merging a more pleasant experience.
 
Going forward, we're purging them from all projects and forbade use of them in new code. YMMV.

Published Tuesday, October 30, 2007 12:29 PM by Bil Simser
Filed under:

Comments

Tuesday, October 30, 2007 3:19 PM by DotNetKicks.com

# Regions == Evil

You've been kicked (a good thing) - Trackback from DotNetKicks.com

Tuesday, October 30, 2007 3:34 PM by Joe Chung

# re: Regions == Evil

Oh man, I _hate_ #regions!

They are cruft from the days before there were partial classes when the Visual Studio team tried unsuccessfully to hide the implementation details of their designer serialization hack from programmers.

It makes me ill to think of how Visual Studio would badly mangle or even destroy Windows Forms designer code because of this ridiculous hack back in .NET 1.x days.

#region sucks!

Tuesday, October 30, 2007 3:46 PM by Jeremy

# re: Regions == Evil

I'll go even farther Bil.  Regions are a code smell -->

codebetter.com/.../129571.aspx

Tuesday, October 30, 2007 3:55 PM by AndrewSeven

# re: Regions == Evil

I've always felt that regions break collapse to definitions.

I battled what I called "the seven magical regions" for quite some time. Aside from the difficulty of separating "Methods" from "Overrides" using the same regions makes all classes look the same ;)

When you can collapse to definitions (I've mapped it to CTRL+D ) the only time I've found that a region increases readability is when you have a method with a bunch of overloaded version.

Tuesday, October 30, 2007 4:23 PM by Ryan Ternier

# re: Regions == Evil

CTRL M-O is your friend, minimzes everything.

I like regions... but within reason.  Whoever wrote that code snippet above needs to be smacked around with a live tuna!

Tuesday, October 30, 2007 4:42 PM by Russell Mull

# re: Regions == Evil

In general I agree - if used consistently, as you describe, they are a bit smelly.  I do like using them to hide code when, if you you look at a the region name, you know what's inside it.  It helps readability a little when we don't have a good metaprogramming facility.  Like this:

#region dependencyproperty int MyProperty

//// dependency property boilerplate

#endregion

I've actually updated by propdp snippet to include that by default.

Tuesday, October 30, 2007 5:12 PM by Chris R. Chapman

# re: Regions == Evil

Oh, man do I agree - I even mentioned it in my tag-along post on "Seven Deadly Sins" back in ought-six (blog.chapmanconsulting.ca/.../Seven+Deadly+Sins+Of+Software+Development.aspx)

At the time I wrote the post, I was working on optimizing some code another team was writing and stumbled on a #region that concealed a method that was, I kid you not, over 400 lines long.

And it was partially written by a senior developer.

I began to automatically strip out code regions from class files as a matter of course after that...!

Tuesday, October 30, 2007 5:40 PM by Darren Kopp

# re: Regions == Evil

I user regionerate. I create methods all through refactoring but when i'm all done i just right click and regionerate my document again and everything gets organized into the appropriate regions and sorts them.

www.rauchy.net/regionerate

Wednesday, October 31, 2007 12:47 AM by Tales from the SharpSide

# Links from the Sharpside [10.30.07]

Links from the Sharpside [10.30.07]

Wednesday, October 31, 2007 4:08 AM by Armen Ayvazyan

# re: Regions == Evil

Agree.

I don't know a case where I would use #region. We have mechanisms how to reorganize a code to be much more readable: split class to separate classes, use partial classes, use method instead big chunk of code wrapped by #region.  I also agree that there are cases where #region is a “Code Smell”.

You've got "kick" from me.

Wednesday, October 31, 2007 4:50 AM by Carlos M Perez

# re: Regions == Evil

You use ReSharper and don't know how to manage your regions? Menu ReSharper, Windows, File Structure Window ... and all your troubles are gone!

Wednesday, October 31, 2007 4:53 AM by s

# re: Regions == Evil

what are you? retarted?

"I have to find where to put the method." ???

tool called Regionerate, man...

Wednesday, October 31, 2007 5:16 AM by Ramon Smits

# re: Regions == Evil

Regions exist for people that cannot do proper seperation of responsibility.

Lots of regions almost always refer to bad code.

Wednesday, October 31, 2007 5:34 AM by Paul Kohler

# re: Regions == Evil

Agreed! I find them an additional and annoying overhead. Keep your code neat and tidy yes, regions (especially nested ones) are simply evil!! I do like to use them for certain grouping especially the 'Interface Implementation' style but on the whole they add overhead, not value.

That raises another issue... the code comments that add no value but double the amount of code! ;-)

Wednesday, October 31, 2007 6:11 AM by Steve Bohlen

# re: Regions == Evil

Like anything that you use to organize anything, without the proper tools your orgnaization system can turn against you if you lack the proper management techniques.

I use ClassCleaner (www.codeplex.com/CRClassCleaner) to re-org my code into regions, sort fields, methods, etc. alphabetically, and generally ensure that my classes are consistently organized.

Without such a tool, yes, I agree regions can become 'the tail-wagging-the-dog' but WITH such a tool (or regionerate, or R#, etc.) regions are both helpful and managable.

The ability to just add a field in the middle of my class, or declare a method anywhere I want and then reorg my class with a single keystroke to move the members where they belong vs. jumping all over the place in the IDE to just add a field @ the top of my class is a huge productiviity enhancer (I find).

Wednesday, October 31, 2007 9:19 AM by Tom Opgenorth

# re: Regions == Evil

I don't think I would say "regions are a code smell".  Depends on how you use them.  

That being said, our favourite hillbilly has converted me into the "you-don't-really-need-regions" crowd.  I've stripped all the regions out of my R# templates, and as I find them in code I remove them.  I find stuff much faster with the various R# enhancements.

I notice a while back in R# 3.0 that R# has a Options..Languages C#...Type Member Layout.  In here it looks like you can specify the rules to apply when you use R# to reformat your code.  I was thinking when I have some free time (on the 9th day of the week) to create my own set of rules to strip out regions.

Wednesday, October 31, 2007 11:13 AM by Steven R

# re: Regions == Evil

I hate regions so much I created an open source project to rid them of your code code.google.com/.../removeregions. Its not finished yet though but will be soon.

Wednesday, October 31, 2007 5:39 PM by Damien Guard

# re: Regions == Evil

It would seem the title should be "Regions == Evil if you use Resharper and spend more time writing code than reading it"

[)amien

Thursday, November 01, 2007 2:22 AM by Jeff Brown

# re: Regions == Evil

I find it completely stupid to separate members of a class by kind.  I know that's a constructor, a property or a method, besides I've already sorted them in the order: fields, constructors, Dispose/Finalize, properties, public methods, internal methods, protected methods, interface implementations, private methods.  (or thereabouts depending on the logical relations between the declarations)

I always disable code folding.  I simply have no interest in expanding regions as I read through a chunk of code: I'll miss stuff.  It's sometimes hard to say which details I skim over will turn out to be relevant.

I'm not afraid of a thousand line file if it's well structured.  Seeing it all is a sign that there's room for improvement.  Occasionally regions are useful in a class with a lot of behavior (like MbUnit Assert) but they can be a code smell too.

More importantly, I treat regions as a coder smell.  Lots of regions tells me that either a coder is OCD or has difficulty reading and making sense of modest volumes of code.  The same symptoms will often show up in the design.  I use this information to my advantage when acting as a mentor.

IMHO, regions a poor substitute for what Visual Studio should have had to begin with: a decent outline view.

Thursday, November 01, 2007 7:18 AM by Some.Net(Guy)

# re: Regions == Evil

I happily use regions in my classes, but only to keep the properties/members separate. It helps, I think, to keep them out of the way, and you can always easily find them. Anything in moderation can be good :)

Thursday, November 01, 2007 4:18 PM by arkban

# re: Regions == Evil

I agree with [)amien -- you've artificially lumped a problem with ReSharper onto C# and argued its all C#'s fault.

All the arguments against regions seem to be that regions hide the code from you. Regions don't hide anything from you, the IDE does. This is like syntax highlighting; if you don't like it tell the IDE to not fold.

No one here has pointed out any actual flaw with regions. Everyone has tried to argue that their personal opinion is somehow "true".

ARKBAN

Saturday, November 03, 2007 9:59 AM by Nikola Maloivic

# re: Regions == Evil

IMHO, regions are decreasing discoverability of the code and makes code reading much harder

I would use maybe regions only to hide non sigle type field declarations and private helper methods (to reduce the code noise)

In general, I was using regionerate but my personal experience is that putting public memebers in region makes things worst.

Offcourse, R# rules! :)

Tuesday, November 06, 2007 10:07 AM by RyanOC

# re: Regions == Evil

If we touch it will we blow up like the parents who were warned? :)