C# regions sure can be useless
I’ve seen many ways of grouping C# source over the years, but one that I never fully appreciated as being disgusting until this year was grouping like PMEs: public methods, protected methods, etc.
Sure, many source formatting guidelines (and perhaps even default StyleCop settings) suggest this grouping style. But, tell me: what is useful about this?
Here’s the Grid.cs source file from WPF. Are the comments helpful? Are the regions?
I’d much rather see this file grouped into like functionality, if regions need to be used: give me size sharing source in one region, basic layout arrangement functions in another, and then perhaps all the dependency properties together.
Not sure what others think, but I hope to never have to open another file like Grid.cs and see this sort of thing. Just not my thing.
Well, it *does* look neat.
But, I can’t really think of a practical benefit beyond that.
Hallelujah
>>> I’d much rather see this file grouped into like functionality, if regions need to be used: give me size sharing source in one region, basic layout arrangement functions in another, and then perhaps all the dependency properties together.
I agreeing your suggestion. Let say if you have grouped data-biding and presentation-methods (functional categories), that makes sense. For enhancement request or for refactoring purpose at one time I may wish to focus on specific area and really don’t want to scroll through all other codes – nice grouping can help that way making the code base more readable.
Thanks!
Dhananjay
A thousand times yes! Categorizing is as hard as naming the classes, and with the same rewards. Ideally, each class would have a single responsibility and be short, but reality seldom complies. My thumb rule is that changes should affect potions of a file close to each other. If a file becomes too large, I split it in several partial classes. I once clustered the partial parts of all classes related to drag and drop in a single file.
I would even go as far as to ban regions completely altogether.
They’re misused more often than not. If you think you need regions, your class is probably becoming too big: refactor!
@JeroenH,
I agree in the simple case, but have seen many examples of massive source files that really do make sense for regions.
UI controls come to mind: there are only so many ways to abstract out the functionality. At the end of the day, you often end up with many PMEs that just need to be there. Controls often end up being thousands of lines long.
And the argument of splitting a partial class out into multiple files, doesn’t feel like a true “refactor” to me: regions or partial classes spell the same end result: a huge class file.
I pretty much only bother with putting Properties into a Region, although AutoProperties are removing the need for this to a certain extent.
I wrote a little about it too: http://www.stormbase.net/region-hate
Couldn’t agree more. I always think this method of breaking your code into regions is like organizing your house by putting all the chairs in one room and all the tables in another.
Let grouping like this be a feature of the IDE.
it doesn’t matter what the file looks like, the ide can show it the way you like.
The only thing regions are usefull for now in VS, is that hey support collapsing the content.
I’d much prefer indentation based collapsing.
I always love the debate around regions. They do not affect performance. They do not affect compiled file sizes (exe, dll). You have the flexibility to arrange them any way you want (within the coding standards of your organization). You even have the flexibility to not use them at all. You are not going to convince people to use/not use/arrange region. People who like them will use them. People whose organization requires them will use them. People who don’t like them won’t use them. I can’t believe that people can’t find real coding issues to debate….Irony I wasting time on a useless debate….I guess I had a few minutes to kill.
I generally group by function performed – code to launch dialogs, code to do database stuff etc.
It comes down to this simple fact for me. If your class is so large you are using regions and they are actually serving a useful purpose. You are probably violating Single Responsibility Principle.
Like most optional things in programming, regions can be great as long as you keep them under control. I use them frequently. After I set up a bunch of properties, I usually don’t need to see them again, so I wrap them in a region. Then for the rest of the code, I usually group by functionality, like someone else said. Then you don’t have to kill your brain trying to remember what order things are in. And no, my classes are not bloated, and do not need to be refactored
Tip: use the ctrl + m, ctrl o shortcut to minimize everything to regions/stubs.
In the beginning I used regions completely incorrectly as well; I thought they were neat in concept, but I used them much like in your example. I’ve long since switched from that mentality, and I believe I now only have them in a few files [wrapping up long, operator overload functionality for example].
I do, however, split my code into private/public functionality sections. I did this so that it’s easy for me to just scroll through and see what I’ve made publicly available from my control, instead of having to dig through the entire page through private functionality.
I agree that regions are overused. Do they have a point when used correctly? Possibly, but they also add bloat to the code proper and can possibly drift out-of-sync with what they’re supposed to “compress” visually.
I especially don’t like it when regions are used to hide parts of a big method. If he method is that big it should really get a refactoring.
I avoid regions as much as possible, and I also cringe each time I see them used to group by member type. They don’t help me understand a class better, I use the navigation bar or Resharper for that. In fact, I think such organization actually make it harder to maintain a class, because related elements, like the fields, properties and methods that work together are guaranteed to be far apart in the code.
When a class becomes monstrous, it’s usually a sign that its got too many responsibilities and needs to be split up. I do use regions to start splitting these huge classes into functionality groupings to help see how to eventually break up into multiple classes. I also like using regions to “hide” code that doesn’t belong (patches), or generated code.
You said it..
Yes it is completely useless way. What we want is a logical grouping instead of the most obvious grouping.
NO. They are so useful for me (at least)..
With you 100% on this. More often than not the first thing I have to do with a file like the one you showed is expand all the regions. Yeah, I know there’s a keyboard shortcut to do that, but it’s still a repetitive task I have to perform every time I open a source file. Just give me the code, I say. I don’t need or want it hidden from me.
Jeff,
Grid.cs sure looks bad with those regions there – no point in having them, in my opinion. (IDE should handle filtering members by visibility.)
I myself never use regions, unless the coding standard of my current employer says I must. That said, I am lucky enough to not be working on any UI components. All my classes are 300 lines max (that includes comments), and if they aren’t at some point, I revisit the object model. (That obsession of mine does not always serve me well. It leads to overengineering sometimes.)
I’m a region lover, in the minority in my company, but I don’t use them quite like this.
Having an ASCII comment then following with a named region violates the DRY principle. Regions are handy for improving readability around large or infrequently read code segments. Property getters, setters etc.
All personal style and little substantial difference either way.
If you have enough different functionality in your classes that you can say you prefer ‘grouping by functionality’ over regions, you are likely doing it wrong (unless you’re _trying to do things procedurally).
I’ve come to feel the same way but sadly I’m the lone voice on this in our company. My colleagues seem to feel that code is somehow less readable if not grouped in this way.