I’ve stopped using regions in my code. And, to be honest, I’ve never looked back. I don’t need them, don’t even miss them. In fact, the more I go on coding without attempting to group my methods, properties, etc., into sections of magically collapsible text, the more convinced I am that regions are unnecessary.
Requisite Caveats: Before I go too far, let me clarify: I’m talking about regions in user-generated code. My concern is really about developers making decisions about how they organize their own code for purposes of readability.
And yes, I’ve used them in the past – repeatedly – in the manners listed below.
They Distract From Refactoring
I look at regions as pseudo-refactoring tools. All too often, their usage is the result of logic like “Hmm, this file is pretty big and unwieldy... I know, I can use regions to get it under control.” Leading to what I consider the fallacy of thinking that by condensing code inside the editor, we’ve made it more manageable. When in fact, we haven’t done anything.
Big files are blazing neon red flags that real refactoring opportunities are at hand. Using regions, however, can trick some developers into thinking that n-thousand lines of code in a single file is really maintainable, because well, see, we’ve got them all organized into nicely labeled areas. They’re a distraction from the real work that needs to be done.
Regions don’t make the file smaller, but they can mislead you into thinking this much code is maintainable.
Personally, I feel that when a file is growing to about 300 or more lines, something is amiss. Whether it’s something like an SRP violation, a lack of optimization, or just that’s it becoming the “miscellaneous” file, a big class usually means big trouble. I’m happy with small. Small is readable; it’s maintainable; it typically doesn’t need regions to stay organized.
They Conceal Surprises And “Ugly” Code
Regions can be, and often are, used to hide ugly and/or mysterious code. The really scary stuff (general cruft, old commented-out lines, or my personal favorite… the “surprise!” code that tends to throw reviewers for a loop) that you know you don’t ever want to see again. And maybe that you don’t want anyone else to see, either.
I’m of the belief that ugly code should never be hidden. You don’t want a “people under the stairs” scenario; that stuff will fester, rot, and mutate… and it will always come back to haunt you. It has to be exposed; literally dragged out into the center of your editor, kicking, writhing, and screaming, so that it can be healed and cared for.
Regions can cleverly disguise code that’s loaded with surprises. Or, at least not what you’d expect when you read their captions…
…and then expand them out to find, well, hopefully something good.
Make Your Code Readable
Readability has nothing to do with regions, in my opinion. It has everything to do with making your code sensible, logical, and straightforward.
The best way to keep your code organized is to think critically about what you’re writing. Don’t rely on editor shortcuts; they can become very addictive habits that are hard to break free from. I put regions in this category; they trick you into thinking you’ve made your code more readable, but in reality you’ve done very little. Far worse, you’ve inadvertently hidden stuff that other developers may need to see one day.
What do you think? Let me know if you still use regions. Do you consider them necessary? And, if so, where have they helped you the most?
Posts
_1098.png){kind=small}
