Home » c# » Just say “No!” to C# Regions? Really?!

Just say “No!” to C# Regions? Really?!

other-042  I just read a post by Casademora on “public abstract string[]  Blog()”

Just say No! to C# Regions « public abstract string[] Blog()

and

I still say Regions are not useful… but…

arguing that not only should we NOT use code regions, but if we do, we are hiding “bad code.”  He uses words like “retarded,” “lame excuse for a preprocessor tag,” etc.

You’d think maybe this guy (gal?) just had a bad day when he wrote this, but no, he goes on to further defend his position in a later post.

And what I don’t understand at all is how his original post ended up on DotNetKicks today.  It’s an old post that was written last year but was just kicked up to the front page?  I figure someone MUST agree with him or it wouldn’t be there.

So, are Regions really as evil as Casademora argues that they are?

First what is a region?

#region Member Variables

private bool _refreshState;
private bool _isRefresh;

#endregion Member Variables

That’s a region.  See the #region and the #endregion preprocessor tags?  They define a named region in your code.

Why do they exist?

Any code you surround with a region is collapsible, just like your methods and properties are.  If you collapse the region above, all you see in your editor is:

image

Are they hiding “bad” code?

The main argument that Casademora makes is that the use of regions hides “bad” code.  He defines bad code as:

Oh… wait!  He never defines “Bad” he only defines “Better.”

But I doubt that anyone could argue that declaration of private member variables is “bad” in any sense of the word.  In fact this code is from one of the best programmers I know.  Here’s a screen grab of the methods in this file:

image

And the code in those methods is just as pretty.  In fact, Mike’s code is consistently well structured, well organized, follows good naming conventions.  I wish my code looked as good.

But when you first open the file, this is what you see:

image

I don’t know about you, but I always feel like I’ve been hit with a breath of fresh air when I open Mike’s code.  Instead of being assaulted with 201 lines of code (that’s how many lines are in this file) I see this.

So the question is, would Mike’s code be as organized without the regions?  So I asked him.

He says, “I’d try to do it anyway, but the regions make it easier.  Like, if I need to add a new private method, I go right to that region.  I find it most useful to separate out the properties and event handlers.”

So, contrary to Casademora’s statement, regions actually help Mike structure his code so that it is easy to read.  They aren’t hiding “bad” code.  If anything they are “hiding” good code.

Hiding Code is Good

When you are working on code with lots of properties, methods, and event handlers.  Do you really need to see the member variables at the same time you are working on an Event handler?  Most of the time we don’t.

Regions, used correctly, make your code more readable, and hide code you aren’t working on so that you can easily find and work on the code you do need to work on.  That’s the whole point.

I’m sure one could find uses of regions that have nothing to do with code structure.  Uses that obfuscate the code rather than making it easier to maintain.  But if you use the code in a logical way, they can significantly increase the readability of your code.

 

Other post in c#

Related Post

  • C# “” better than string.Empty?C# “” better than string.Empty? I recently read an article that argued that “” is “Better than String.Empty” The argument is that since string.Empty doesn’t work in all situations, we should not use it at all.  He […]
  • .Net String Pool – Not Just For The Compiler.Net String Pool – Not Just For The Compiler On Monday, I was corrected in my assertion that creating multiple empty strings would create multiple objects.  Turns out the compiler automatically puts all of the strings that are […]
  • Dispose, Finalize and SuppressFinalizeDispose, Finalize and SuppressFinalize I got the following question recently. What is the difference between Dispose and SupressFinalize in garbage collection?” The problem with this question is it assumes Dispose and […]
  • Unsafe Mode in C#Unsafe Mode in C# One of the "advantages" of using CSharp instead of VB.NET is that if programmers want to, they have the option of bypassing the memory management of .NET and working with memory […]
  • What is the global keyword in CSharp?What is the global keyword in CSharp? During the Christmas break, I received the following question: What does C# global keyword actually do? Code example, from table adapter […]

About Dave Bush

Dave Bush is a Full Stack ASP.NET developer focusing on ASP.NET, C#, Node.js, JavaScript, HTML, CSS, BootStrap, and Angular.JS. Does your team need additional help in any of the above? Contact Dave today.

  • I agree with you 100%

    Regions are good. However like almost anything they can be used badly.

    I’ve lost count of the times I’ve seen region groupings like

    #region Don’t know what these are for

    or

    #region Not used

    or

    #region Old code

    or

    #region Steve’s Code

    or

    #region Calculations for SomeMethod

    The reason these are bad is the same reason that comments like this are bad. If the code changes, the regions don’t make any sense.

    Like any construct regions should be used with care. I think the pattern you observe here is the only real correct one. I’d even go as far as to say that there should be an option to autogenerate for these regions in resharper with remove/add functionality with no other regions allowed.

  • Dave Schinkel

    Whoever says regions are not to be used, I’d love to see your code. I bet you it’s a mess and the reason you don’t like regions is because the developers on your team has abused use of them and that there is no logical pattern or team standard established.

    I’ve been on plenty of teams who have used regions effectively and at a top level grouping that made classes and finding things much faster overall. I definitely agree that unorganized use of regions and overuse should not be, but to say not to use regions at all is like saying put all of your damn html on one line and don’t indent…another thing I can’t read.

    If you have a team who can’t use regions effectively it’s either because

    1) They don’t care about team standards
    2) There is no pattern in place and standard that expected of the team
    3) There are no code reviews to help keep that standard and pattern in place

    there is absolutely no excuse to say that regions are not helpful. It’s called a standard people and reviews. It’s called caring about code structure which goes along with namespacing, file structure of you project, and pattern structure of your code. To single out regions is foolish and only means you can’t figure out a standard practice on your team and template to force and use that is top level..simple as this:

    #region Methods
    #region Properties
    #region CRUDs

    who wants to scroll down a class all the time when you can go to a region quickly to find what you want as a starting point. And your classes should never be very long (SOLID) but still, regions do help. If Code Generation did not use regions, can you imagine? Granted I am not using code generated code now but was and it was nice.

    I always use regions and always will, they are not chaos in my application so they are extremely useful when not used like a code & run team who has no clue of standards or patterns.

  • sth_Weird

    I totally agree with you!
    I use regions the same way your collegue does. When I want to add a new property, field, event etc. in my file, it’s simply the easiest way to go that region. I’ve seen collegues, who are actually good programmers when you look at the result, but never look at their code, there’s no structure in it, there are events between properties and functions between constructors, just because they added them right where the cursor was when they wrote them.
    Of course, you do not need regions to organize your code. But as you said,…do you really want to see the the events and constructors and variables when you edit your properties? I don’t. And even if you grouped your code so that the constructors come before the properties and after that the functions…if you have a lot of them, you still have to look through all of them to find what you need, it’s much easier to simply open the region. For me, the only reason not to use regions is that you do not want your code to be organized (if somebody else looks at your code it of course looks much more impressive and complex if he sees hundreds of functions, than three or four regions), you want it to look complicated, or you are too lazy to keep it organized.

  • It’s fine to use #regions to hide bad code, as long as you type “Bad Code In Here” as your region text. I use them to hide the sloppy, inefficient parts of my algorithms. It leads to code that is much more readable and elegant-looking.

  • In seriousness though, StyleCop actually discourages using #regions. I’m not exactly sure why, though. I wish that StyleCop had explanations for each of their style decisions.

  • sth_Weird

    I see a lot of posts saying “this and that tool will group your properties/function etc. anyway” and things like that.
    We don’t have StyleCop or anything similar in our company.
    I don’t know StyleCop or any other of those tools, but I guess they are either expensive or they are freeware and we are not allowed to use freeware unless authorized by our it-security department and we won’t buy tools that we actually don’t need. And I’m surely not going to buy any of those tools for private use.
    So people who insist on not using regions, pointing to tools that order or structure your code should keep in mind that if you really produce “nice” code then you should not need this tools, and actually that’s the main argument against regions, because they might hide bad code or be useless because you should not need to group constructors etc. with them.

  • ozzy

    I agree. I use regions to partition my ‘fat’ classes so patterns can emerge. I can discover what should be grouped together in a different class or namespace or even project.