Goodbye, #region

I have been shying away from #regions for awhile now, but the deal clincher occurred after I read Clean Code (review coming soon). I have always thought that good code looks good. The book makes a great argument for this by describing how good code "reads like a story". You can read it top to bottom. It contains descriptive, well-purposed names and the methods appear (generally) in the order they are used. Additionally, a good class contains a single story. That is, it should have a single responsibility (SRP) - one reason to change.

As I see it, #regions:

1. Prevent me from reading the story. If I have to open #regions to inspect a class, it hinders my flow.

2. Prevent me from writing the story in the first place. For example, a class whose methods are grouped into #regions called public, private, and protected, does not make for a good story. It's a bad read because I can't follow the code from top to bottom. I end up bouncing around the code like a spider-monkey playing ping-pong. This makes it difficult to ascertain the purpose of a class that I wrote a long time ago.

3. Might indicate that I have more than one story. If I am grouping methods together based on the purpose of the methods, it may be an indicator that I am dealing with a class that needs to be split up.

4. Could possibly be nothing more than a bad comment. One attribute of a bad comment is that it is redundant in regards to the code that it is describing. #regions can be like that sometimes. Consider a #region named "Public Methods". I can look at method and clearly see it's accessibility. Why denote it twice?

5. Are unnecessary because I use ReSharper. It is trivial to navigate code using ReSharper. If you are a .NET developer and not using a tool like ReSharper or CodeRush, you might as well be coding with one thumb. With ReSharper I can use ALT+DOWN to scroll between the methods of a class or CTRL+F12 to jump directly to a method.

6. Are kinda crufty. They are there so the IDE can collapse/expand regions of code. They don't really do anything.

That's all I can think of right now, but these are enough reasons for me.

October 22, 2008 03:58 by JP
E-mail | Permalink | Comments (4) | Comment RSSRSS comment feed

Comments

October 22. 2008 04:39

Koby

While you make some really good points, I think #regions are a personal thing. Some people use them, others do not. For those that do not, it is nothing to hit Ctrl+M+L to expand all the regions.

We've had this discussion before at the Alt.NET dinners. I use regions to segregate work. Also there is a certain amount of mental capacity that can be wasted when ALL the code is displayed and once and I only want to work on a very small segment of it. Also, just because one decides to use #regions, does not mean that their code is not clean.

Koby

October 22. 2008 05:16

JP

Well, the argument could be made that if your class is so big that you need to collapse portions of it....it's too big. If the classes methods in the class are displayed in the order they are used, I fail to see how that would strain me mentally. The only place I could see keeping regions for are event handlers.

JP

October 22. 2008 10:22

Eric Geiger

I have found myself just sort of naturally moving away from regions, but I don't think I'm at the point yet where I'm staunchly opposed to them. I just don't like having code... any code at all... hidden from view anymore. If it needs to hide, something is wrong; either in design, intent, or simply that (like you mention) the file is getting too big.

Eric Geiger

October 24. 2008 15:35

Jeremy Wiebe

The more I _don't_ use #regions, the more I don't like them. They have a tendency to allow developers to grow a class far beyond the size any class should be (one such offending class was over 1000 lines long, but fit into the screen when the regions were collapsed... YIKES).

@Koby: It's nothing to expand all regions in C#, I'll agree, but I have yet to find the magic keystrokes to do the same in VB.NET. Maybe that's yet another half-baked, protect-the-developer decision that the VB.NET team inflicted on us developers. (No, I'm not bitter) Wink

Jeremy Wiebe

Comments are closed