Why Regions are Fugly
I hate the #region construct with the fire of a thousand suns. I’m serious; they absolutely drive me nuts. Why? They slow me down and make me hunt through to find what I’m looking for. CTRL+I (incremental search) and CTRL+M, CTRL+O (collapse to definitions) and good design principles are all you need.
Here are common reasons you might think you need a #region, with a corresponding reason you don’t.
#1 - Group members of an interface implementation.
Not necessary. I can see you’ve implemented the interface right after the class. I look there.
#2 - Organize a large class.
Generally not necessary (see #5). For most classes having to resort to regions to make the class manageable is a design smell. Simply put: your class is too damn big. Break it apart by responsibility. Tiny classes people.
#3 - Organize a large method.
What stinks? Seriously if you’ve got a huge method here, break it apart. We’re not doing procedural, we’re doing OO. Maybe you need a collaborator to do some work.
#4 - Group types of members in a class.
This is, in my estimation, is the most inelegant, inhuman — as in robotic — violation of good source code aesthetic. I’m talking about the overly structured class with #region Methods, #region Properties, #region Constructors, etc. It’s just too anal retentive (even for me). Just stack them in order and you won’t need regions. Put things in plain view!
#5 - Group a huge class that’s a Ordered Fluent Interface.
Hmm… Maybe. Okay, so this is where I make a concession on #regions. If you’re going to compose a method chain that employs the IAfterSomeMethod technique I can live with that. There’s an exception to every rule, no?
Drew Marsh wrote:
Color me anal rententive. :\ While I agree whole heartedly with most of these, I enforce #1 & #4 here because it’s been my experience that without some kind of format like that the devs won’t remember to keep the stuff together. I do regions for:
Fields, Constructors, Type specific (meaning to the class/interface) methods, Type specific properties, Interface implementations, Helper methods, Nested Types.
Later,
Drew
P.S. We gotta grab some Lombardi’s again soon! ;)
Posted on 22-Jul-07 at 10:22 pm | Permalink
Dave wrote:
I knew I’d get some controversy outta this one :)
Definitely gotta get together soon. It’s been an unusually busy summer.
Posted on 22-Jul-07 at 10:54 pm | Permalink
Derik Whittaker wrote:
Dave,
I would have to disagree with you 100% on this one. Epically #4.
I believe that regions are great, they allow me to be more productive and find code much easier, faster.
If i know a method is private, why filter through all the public ones to find it. Simply expand the private region and i have what i want.
Derik
Posted on 23-Jul-07 at 11:37 am | Permalink
Dave wrote:
@Derik - So click, click, click to find intent? I can’t stand that. Nor do I lookup things by access modifier. CTRL+I to the method name. All this said I do sort the members by type then access modifier.
All specifics aside when I’m finding code 9/10 times it’s to try to grok what someone else wrote. If there’s a BDD-style test this is the best way, by far, for me to see the pieces. If not, well why not?! Okay, accepting there isn’t a nice, expressive test my heuristic then takes me to looking at class names or a pointer from the author (if available). At that point, 95% of classes should be so small as to not need regions.
Posted on 23-Jul-07 at 11:50 am | Permalink
Shawn wrote:
I agree fully. I have set VS to basically ignore regions so they don’t bother me.
I find that the motivations behind heavy usage of regions can generally be satisfied with other tools such as Resharper. If you consistently use something like Resharper 3’s Format Code to keep all of your classes consistently formatted that, in combination with smart Go to Declaration and Incremental Search should be all you need.
Regions strike me as a hold-over VBism, which is probably why they are so popular.
Posted on 23-Jul-07 at 12:10 pm | Permalink
Ollie wrote:
Not a problem if all classes only have single 25 lined method with no class parameters or constructors :)
this OO thing is overrated as well :)
Posted on 24-Jul-07 at 7:01 am | Permalink
LosManos wrote:
hejdig.
Especially working close to the user interface classes tend to get big. At least one method per user action, and user actions are plenty in a GUI.
During my years pretending to work I haved found out that a “form class” contains several parts where one is the event sink where all events from the surrounding world is caught. This region I call “Event handlers” or “Event sinks”.
( Yes, I have names for the others to but that is out of scope. )
I have two solutions (besides inventing some fancy class relation-inheritance-interface-composition-pattern structure)
1) divide the class into files with “partial class”
2) use regions
Both ways work good.
/OF
Posted on 26-Jul-07 at 2:22 pm | Permalink
Mat Hobbs wrote:
Until we get some super IDE that auto-magically and reversibly organizes code in some wonderous display (markup for code?), we will have to live with manual orderings and arrangements of code.
I don’t get you how rip regions but say: “Just stack them in order and you won’t need regions. Put things in plain view!” sounds like you’re contradicting yourself!
Most classes are small, but some are big, that’s life. Sometimes a module is… a module.
Posted on 27-Jul-07 at 12:47 am | Permalink
Dave wrote:
@Mat - How is that contradictory? I prefer things in plain view. As far as the super IDE goes… I want one!
@LosManos - For these GUI classes I like MVP. In the view I too like the “WireHandlers” (or similar) method. I use anonymous delegates where possible that generally call right back into the Presenter. Easy to read.
Posted on 27-Jul-07 at 3:58 am | Permalink
Commonality wrote:
Regions and Readability…
…
Posted on 30-Jul-07 at 9:41 am | Permalink