In addition to my previous comment, regions are great in WPF when you don’t want to see all the junk associated with dependency properties, routed events, etc.
Count me in as fan of regions. As others have said, they are useful for hiding the likes of numerous attribute declarations, etc.
However, I do agree with most of your objections, they are very prone to abuse. Many times the desire to use a region can be taken as an opportunity to consider refactoring. That’s the clue I use personally in any case.
I also feel your pain, there is a member of my team who shall remain nameless that insists on profuse (imo) use of them. It is painful to read files he’s written.
Right click, Outlining, Stop Outlining.
Job done. But you knew that already.
Meh. I think the most important takeaway here is that #regioning is a code smell. For me, I don’t see much regioning since I usually browse by Go To Definition, which necessarily expands the region.
Sounds like most of the proponents of code-folding believe that it reveals the outline by hiding the details. I submit that, when we’re looking at code, the devil is in the details
Regarding partial-classes, my .02 is that they should only be used to separate auto-generated code from programmer-generated code.
As I said above, if you have to delve into the implementation of a class before you can use its public interface then that is a definite code smell!
I do not know how Visual Studio works, but emacs incremental search is so not-painful to use that I can’t really express it. I see this folding feature that my friends from college use and I have been only disgusted with how much time they lose using the mouse to code while using it (and other features from those fancy IDEs).
I have been using XEmacs to program in C for some months now and I can say that I will probably still use it for the rest of my life.
I used to commonly write a class and then reorganize my methods into groups that were logically related. Once I had all these nicely formatted regions I would then realize that each one represented a class that my original class should be refactored into.
Of course, I didn’t refactor; I just stopped using regions.
@Tom: The best part about that is that no matter your preference on this issue, both sides can peacefully co-exist!
I’ve got two outline regexps for C++ in Emacs. One uses only method names and doxygen headers, the other adds on method-internal comments.
I defined these at first to get the IDE feature into Emacs, but I’ve stopped using them lately. Between tags-apropos and C-s/C-r I haven’t needed folding.
Remember what Steve Yegge said about arranging stacks of screens of Tetris games? The #region problem is a symptom of your larger issue: boilerplate demanding superhuman code organization. You need an IDE so you can use your IDE. I think he’s got you on this one.
When you open up to some nicely collapsed regions, that energy is saved and you can quickly find the relevant section of code.
Not necessarily. You might spend more energy trying to work out if the relevant section is Handlers or Miscellaneous. Or worse, protected functions or public functions.
The major problem here is that region is either semantically defined, which varies wildly by programmer, or syntactically defined, which normally means that they’ve taken the one bit the editor handles most easily (sorting/filtering functions by privacy level), and layered a fold over the top. This would be fine if protected and public functions were always clear from context. But as there’s no reason every function in your code can’t be public, as long as everyone agrees never to use them (private by mutual consent guuuh), this simply isn’t reliable,
The main issue i have with regions is it forces all viewers into the same visualization of the code. Weather or not it is a good organization or not it forces that View of the code on the reader. When a class with regions are poorly organized it harms all viewers.
And poorly organized is relative to the ideal conceptualization you need, ie: the mental picture.
The most common and in my mind most annoying #regions are grouped by:
Why? This is arbitrary organization based on the parts and not a conceptual model. It would be like organizing a book based on verbs, nouns etc instead of the normal conceptual model, units of time (ie chapters).
Good organization would be regions based on Interface implementations, Class overrides etc.
Control visual element hook-up
This organizes based on logical separation of concepts.
However this is still not perfect. Because any newcomer to the code will be forced to view the code with the organization I chose in my regions. If that organization doesn’t work for what they are doing(the conceptual model they need), they are forced to work against that model. They will end up expanding the regions, trying to block them out mentally, while attempting to make the code coherent in their mind.
There’s a lot of things Visual Studio could do better if Microsoft bothered to copy the competition.
There’s a lot of things the competition could do better if they bothered to copy Visual Studio.
C’mon, the last time I tried Eclipse (no that long ago), it didn’t even have File | Save As. Not in every case, but generally speaking, Visual Studio let’s me get my work done without a lot of BS. Most of the competition may have some fancy new features that are very well done, but then basic stuff that Turbo C++ had 20 years ago isn’t even there.
I definitely think it is very bad practice to utilize editor/IDE tricks to avoid having to make things readable. Just hiding the ugly bits of the code, instead of actually spending the time thinking about it and finding a cleaner way, is just another lazy way of injecting spaghetti into your system (gotos were useful too). It is the type of problem that only gets worse with time. It is far easier to make a mess, then it is to write decent code.
This is a lot like the ‘var’ discussion. Yes, in the wrong hands it can be misused. If you’re a bad programmer, you’ll always be a bad programmer, no matter what language, Studio, or how many or how few language features.
Don’t gimp my language/tool because someone else might misuse it!
This is why everything comes with a damn warning label: Caution: if you’re a moron you might cut yourself with this knife.
I want my editor back!
'Don’t gimp my language/tool because someone else might misuse it!
This is why everything comes with a damn warning label: Caution: if you’re a moron you might cut yourself with this knife.’
Dull knives cut fingers… not sharp ones.
@Paul: I definitely think it is very bad practice to utilize editor/IDE tricks to avoid having to make things readable
It’s worth pointing out that #region is NOT an editor/IDE trick.
It is a recognised part of the C# language, according to the ECMA standard:
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-334.pdf (see section 9.5.6)
Emacs is getting a lot of attention in this post. I think it’s because it was the first IDE (or one of the first), so basically everybody wants to compare a cool feature with the one that is presented in emacs. Emacs is so, so old that is hard to consider anything that does it differently from Emacs to be better. For most things that is true, for others it’s just a different convention derived from the enviroment. In the case of incremental search I belive it’s hard to be better than emacs, ctrl+s to incremental search forward from the cursor, ctrl+s again to search for the next word, the same with ctrl+r for backward search.
I’ve been reading this blog for a few years now and I normally agree with about 90% of what Jeff writes about, but I highly disagree on this matter. While writing clear, concise, logically-organized code is certainly the goal, we all know it’s not always possible. I do the best I can, but there is often a lot of extra setup code and such that I don’t need to see while I’m working on other things.
And having wrestled with ADHD/Primarily Inattentive Type thoughout my life, the ability to easily hide sections of code that I don’t need to be concerned with at the moment is probably my single favourite feature in VS.NET (as compared on VS 6.0). It’s a huge productivity booster for me to be able to selectively hide pieces of code that distract me and contribute to mental clutter. I would guess that most programmers probably can’t relate as I don’t think that the ADHD brain style is especially suited to the task of programming.