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?
GitHub
LinkedIn
Twitter