If your boss looks at this folded code he is going to think, I pay you all this money and you have not written any code
If your boss looks at this folded code he is going to think, I pay you all this money and you have not written any code
Well, overusing regions is bad practice, I agree. But this is another way for structuring the code, like splitting the classes to files. The same way one might say, that all the code should be in one file, because then you won’t need to browse a huge solution tree. Just one file and … incremental search …
It large files this is incredibly helpful… less you scroll forever and ever to find what you need. The extra mouse click to open them is well worth the time it would take to scroll through a whole bunch of stuff you don’t need.
I initially didn’t like regions, but then I started working with larger code files and realized how useful they can be. My biggest disagreement with Jeff’s four points is number 3. Sometimes you may have a perfectly clean code file that simply has to be long, for various reasons, and regions make it easier to get around and find the parts you’re looking for. So put me down in favor of #region.
I love regions. If you did a survey, I bet 90% of
Visual Studio developers will say they use regions
and love them.
I think that it might be good to point out that the editor in question already does code folding on the function level (and the xmldoc comments have built in folding already too). regions are a way to group collections of functions into a higher level bucket that can be folded at one time.
That being said, I prefer smaller, lightweight code bases that do not require massive folds to make things manageable.
It often amazes me how narrow minded and black and white we coders are. Everything must fall into good or bad buckets.
Yes, if you write crappy code and then hide it #regions then your a loser, but it isn’t the #regions that made your code worthless…It’s your code. Taking it out of the regions (or putting it in) didnt change the code.
Instead of looking at it a hiding, I prefer to think of it as black boxing. That code is solid and stable and doesnt need to be thought about.
But this idea of whining because we had to set one more config option in order to not have to expand the code manually is a little absurd.
I would rather see that someone took the mental-time to organize the code in some fashion than to have to hunt all over to get from method to method.
Just my two-cents…
I used to think that regions were great until I opened up a file that someone else had written and all of the code was folded. It was a waste of my time to have to unfold it all so that I could read the code and get on to my task. Now I don’t use regions. I also disagree about folding comments. If the comments are useful than they should be visible. If there is a reason to hide them in a region, then maybe the comment shouldn’t be in the file.
Why are people complaining about code-hiding? We do it everytime we create a class file. If you don’t loke hidden code, then by all means code in a text editor. Textpad is where I do most of my coding in. Sure it doesn’t do any autocompleation or other nifty gadgets, but your code is EXACTLY the way you want it.
sarcasmMake everything Global while you are at it. After all Global vars and expressions are faster and cleaner./sarcasm
Right on, Jeff! In practice, regions are a band-aid on bad code. They seemed nice when they were first introduced. Now, I wish they’d never been introduced. They give the illusion of nice, neat code. If you need to organize the code, use the language elements to do it. Also, I can’t stand having to open those damned things up. I don’t need all the properties in one place, all the private methods, in another.
I have to agree, but it’s an opinion I don’t hold as strongly. They annoy me, but I don’t actually hate them.
In 2005 and beyond, they simply introduced another feature, Partial Classes, that got rid of the the horrible hand off region section.
This is a great point – until Partial Classes existed, #region was necessary to hide the required generated code.
As for comments I think I’d like to see the class and method comments moved to a seperate file, as they’ve rarely been useful on code I’m working on. I’ve only really found them useful when you got the dll for some third party library and no source to reference.
The presence of massive XMLDoc comments bothers me as well. It’s necessary, but it gets in the way so often.
The fact that we even have a #region directive is part of the problem. With a good editor it shouldn’t be necessary, and all folding would be optional. I wish the Visual Studio editor was smart enough to fold XML Comments down automatically – or even fold down methods automatically. It’s not, even in 2008. Example here:
I have read about this kind of VS code folding before and I did not like the sound of it at all. I have never liked any kind of code folding at all until i started using mylyn (except maybe some minor imports and comments folding).
Eclipse + mylyn that does class/project tree folding and source code folding that is associated with a task. The task can be an issue in an issue tracker and you can save the task’s folding into the issue tracker. It is really good when working with both big and smaller sets of files… I guess that most of you know this but anyways…
Here is some information on mylyn folding: http://www.ibm.com/developerworks/java/library/j-mylyn2/
A lot of people here seem to think that regions are the only way to hide code. But they’re not the only way, nor even the best way. Here’s a better way.
In VS, go to Tools Options Environment Import and Export Settings. Copy the path and filename in the Automatically save my settings to this file box. Then open that file for edit. (Not sure if you can do this in VS and still have it work right, but otherwise use some other XML editor.) If in VS, hit Control-K, Control-D to format the whole file so it’s readable.
Find the KeyboardShortcuts section. Then find the UserShortcuts section within that. If you’ve customized your keyboard at all, you should see various lines starting with Shortcut or RemoveShortcut. (If you can’t find these sections, go into Visual Studio, customize a keyboard setting, then open the .vssettings file back up and look again.)
In among the Shortcut/RemoveShortcut lines, paste these:
Shortcut Command=Edit.ToggleAllOutlining Scope=GlobalAlt+Right Arrow/Shortcut
Shortcut Command=Edit.ToggleOutliningExpansion Scope=GlobalAlt+Down Arrow/Shortcut
Shortcut Command=Edit.CollapsetoDefinitions Scope=GlobalAlt+Left Arrow/Shortcut
RemoveShortcut Command=View.Forward Scope=GlobalAlt+Right Arrow/RemoveShortcut
RemoveShortcut Command=Format.SpaceAcross Scope=VC Dialog EditorAlt+Right Arrow/RemoveShortcut
RemoveShortcut Command=Edit.CompleteWord Scope=Text EditorAlt+Right Arrow/RemoveShortcut
RemoveShortcut Command=View.NavigateForward Scope=WebBrowserAlt+Right Arrow/RemoveShortcut
RemoveShortcut Command=Format.SpaceAcross Scope=VC Dialog EditorAlt+Left Arrow/RemoveShortcut
RemoveShortcut Command=View.Backward Scope=GlobalAlt+Left Arrow/RemoveShortcut
RemoveShortcut Command=View.NavigateBackward Scope=WebBrowserAlt+Left Arrow/RemoveShortcut
RemoveShortcut Command=Format.SpaceDown Scope=VC Dialog EditorAlt+Down Arrow/RemoveShortcut
What does this do? It remaps some Alt+arrow keys. Alt-Left now does Collapse to Definitions; Alt-Down toggles the item you’re on; Alt-Right toggles the whole file between completely expanded and completely collapsed.
So when you open up a code file and the code is sprawled everywhere, just hit Alt-Left and it collapses neat and tidy, but you can still see the members. On the member you want to work on, hit Alt-Down to open it. (Or just double-click on the […], of course.) If your file contains several classes, use Alt-Right (you may have to hit it twice) to collapse everything, even the class definitions, so you can open just the class you want.
All the code hiding you could ever dream of, and you don’t have to use regions for any of it.
What’s the big deal against regions? It’s just a cheap IDE trick - didn’t Code Complete wish this existed a while ago? Any feature/trick can abused if misused by an bad coder.
I peronally love them - I hide away my member/property declarations for when I’m not dealing with that stuff and working on business logic. Sure I can scroll to the bottom, but why bother every single time? I use it as a part of a naming/layout standard - which I actually picked up from a dev team on a gig.
As per my twitter post - you’re illogical to me on this one - I think implicitly typed local variables can get you in about a billion times more trouble in the wrong hands than regions.
Is it okay to trash developers that are no longer on the team?
I agree with you 1000%, Jeff. I think the comment regions are a code smell is spot on. Using regions to organize code or manage complexity is using them as a crutch to enable inordinately long code blocks and poorly factored classes. A class or method that is complex enough to need regions is almost certainly doing too much.
I too hate the fact that when you open the code in the editor you don’t see the code. If I didn’t want to see the source, I wouldn’t open it, dammit. I always disable automatic auto-outlining in Visual Studio for that reason (and region generate for interface implementation as well).
I also find that regions are rarely applied consistently. Some people fold by property/method/constructor. Others by public/private/protected. Neither really add any value, they just make it harder to navigate the code.
I have to completely disagree. Boilerplate crap is a fact of life in the Windows programming world, and the #region directive brings some kind of sanity to that.
If you really want to navigate your code base you’re not doing it by scrolling through a single file’s edit window anyway; you’re using Ctrl-F12 to skip through definitions or using the class browser.
I’m not sure if that’s been mentioned before and I’m not ready to read 150+ comments (sorry!) but I think I’ve got a point worth mentioning.
I believe that, unfortunately, and despite good intentions, Regions should be considered evil. Why? Because they lie. Region titles make strong claims, e.g. “Private members” claims that this region only contains private class members. But of course, the compiler won’t check this assertion, it won’t check whether the region really doesn’t contain public methods.
I’ve come across situations where I’ve searched myself silly because the region captions were lying to me (and yes, I wrote these captions so I’m guilty). But the fact remains that this has cost me much time and I have learned to give any constructs that give redundant, unchecked information a very wide berth. Regions, in my opinion, are very good at hiding vital information while making false claims.
Regions are an organizational tool. They can be very helpful, and if you haven’t found them to be so, then that’s fine. I’ve yet to run into a situation where regions were involved and my life was on the line…maybe everyone else here works in a more intense environment than I do.
Outlining can be turned off within Visual Studio, and as it has been pointed out, everything can be expanded in a couple of quick clicks. So it seems like the worst your co-workers have done is added a few goofy lines (similar to some odd form of commenting) to the otherwise pristine code. Since any good code file is apparently contained in approximately one to two pages (as I’ve learned from the comments), then I don’t see that this is really worth mentioning.
It seems to me that the two arguments that keep coming up against using regions, have boiled down to something like this 1) I’ve seen abuses of regions, therefore regions suck, or 2) I don’t like regions; therefore regions have no value; therefore if you need to use regions, then you’re obviously not up to snuff on your mad koding skillz!1. There’s some dogmatic assertions here today.
And besides, if you don’t see the usefulness of regions, then, obviously, you’re doing it wrong