Code Folding (Regions)
-
I like code-folding as an option ! I think judicious use of it often helps me switch from narrow-focus on some particular functionality back to 'big-picture' view. I have wished for the ability to 'fold' ... just one level of folding would do ... in CP articles :) ... imho this would enable having a top-level highly readable article with lots of minute-details, digressions, footnotes, etc., hidden, but available. best, Bill
"Use the word 'cybernetics,' Norbert, because nobody knows what it means. This will always put you at an advantage in arguments." Claude Shannon (Information Theory scientist): letter to Norbert Weiner of M.I.T., circa 1940
BillWoodruff wrote:
I think judicious use of it often helps me switch from narrow-focus on some particular functionality back to 'big-picture' view
I agree with this. The same principle applies to comments, and those who think code is self-documenting don't seem to get that. Sure, you might be able to get what the code does relatively easily by reading it, by why not save some time and read a comment that explains it more succintly instead? And having them at different levels (group of code, method, region, class, project, application) gives you more choice of exactly at what level you want to understand the code.
BillWoodruff wrote:
I have wished for the ability to 'fold' ... just one level of folding would do ... in CP articles
That's actually something on my TODO list... I want to find out if there is some way to do folding (of sorts) in the company wiki (useful for instruction documents that go into great detail but only need to be read at a higher detail for those who are more experienced).
Somebody in an online forum wrote:
INTJs never really joke. They make a point. The joke is just a gift wrapper.
-
I was just searching for a way to collapse LI tags in the Visual Studio editor without having to manually right click it and select "collapse tag" when I got distracted and read Coding Horror: The Problem with Code Folding. I am a big fan of code folding, and here are some points Jeff makes that I disagree with:
- "I can't see anything!" Actually, you can. You can see the first line of whatever is being folded. In the case of regions, you can see the name of the region. When I am doing web development, I tend to wrap code into regions like "Event Handlers" and "Private Methods". If I want to get a feel for how the program flows, I go straight to "Event Handlers" and look for something that looks like the page load event handler (or init, or what have you). Or if there are constructors, I'll look there first. If I just want to see what properties are available in a user control, I'll go to "Properties" (and since the properties are folded, I can ignore their implementation). I find hiding stuff I don't need to see speeds this process up.
- "Folding directives are glorified comments. Why, exactly, are we writing code to accomodate the editor?" Comments are good. Regions are like comments with a bonus feature (folding a region of code that doesn't otherwise get folded). That's not a bad thing. And we're not accomodating the editor... we're accomodating ourselves and other developers who will come in later to see nicely organized code.
- "Folding is used to sweep code under the rung. Folding is used to mask excessive length." No doubt, when it's used wrong. Just don't use it wrong. Simples. Still, there is some value in hiding information that you don't need (it distracts you less and frees your mind to think of what you are trying to focus on).
- "Folding can hide deficiencies in your editor." From another perspective, it replaces a feature seen in other editors. Sometimes I may want to put all my methods into a "Methods" region. Or maybe I'll put them into "Public Methods" and "Private Methods" regions. Or maybe I'll put event handler methods into "Event Handlers". And so on. Relying on an editor to group these sections automatically may be less flexible and so less useful than if a developer were to choose the regions himself or herself. Perhaps a conversion class is organized into regions according to what data type a method operates on and maybe a user control class
AspDotNetDev wrote:
Folding is used to sweep code under the rung
I hope he means rug, I'd hate to have to carry a ladder to work. I'm a boring class per file kind of guy but I work on a pretty big c++ code base so the granularity of header files and their use can have a big impact on build times. I thought the regions were pretty cool in c#, what I disliked was the partial keyword and classes spread across multiple files.
-
AspDotNetDev wrote:
Folding is used to sweep code under the rung
I hope he means rug, I'd hate to have to carry a ladder to work. I'm a boring class per file kind of guy but I work on a pretty big c++ code base so the granularity of header files and their use can have a big impact on build times. I thought the regions were pretty cool in c#, what I disliked was the partial keyword and classes spread across multiple files.
:laugh: If the darn paste functionality wasn't so munged up, I wouldn't have made that mistake. And uses for the partial keyword by a developer seem rare, excluding their main use (splitting out code for the designer file).
Somebody in an online forum wrote:
INTJs never really joke. They make a point. The joke is just a gift wrapper.
-
I liked that term when I first heard it as opposite to Spaghetti code. :) And there also was Lasagna as description for strictly layered code. Hmm, for application logic and data access you best use both Ravioli code which at the same time is Lasagna code. This is getting confusing and making me hungry :)
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse. -
if you need to fold, maybe you have too much stuff in that one file.
+1 for us dinosaurs :)
"mostly watching the human race is like watching dogs watch tv ... they see the pictures move but the meaning escapes them"
-
I was just searching for a way to collapse LI tags in the Visual Studio editor without having to manually right click it and select "collapse tag" when I got distracted and read Coding Horror: The Problem with Code Folding. I am a big fan of code folding, and here are some points Jeff makes that I disagree with:
- "I can't see anything!" Actually, you can. You can see the first line of whatever is being folded. In the case of regions, you can see the name of the region. When I am doing web development, I tend to wrap code into regions like "Event Handlers" and "Private Methods". If I want to get a feel for how the program flows, I go straight to "Event Handlers" and look for something that looks like the page load event handler (or init, or what have you). Or if there are constructors, I'll look there first. If I just want to see what properties are available in a user control, I'll go to "Properties" (and since the properties are folded, I can ignore their implementation). I find hiding stuff I don't need to see speeds this process up.
- "Folding directives are glorified comments. Why, exactly, are we writing code to accomodate the editor?" Comments are good. Regions are like comments with a bonus feature (folding a region of code that doesn't otherwise get folded). That's not a bad thing. And we're not accomodating the editor... we're accomodating ourselves and other developers who will come in later to see nicely organized code.
- "Folding is used to sweep code under the rung. Folding is used to mask excessive length." No doubt, when it's used wrong. Just don't use it wrong. Simples. Still, there is some value in hiding information that you don't need (it distracts you less and frees your mind to think of what you are trying to focus on).
- "Folding can hide deficiencies in your editor." From another perspective, it replaces a feature seen in other editors. Sometimes I may want to put all my methods into a "Methods" region. Or maybe I'll put them into "Public Methods" and "Private Methods" regions. Or maybe I'll put event handler methods into "Event Handlers". And so on. Relying on an editor to group these sections automatically may be less flexible and so less useful than if a developer were to choose the regions himself or herself. Perhaps a conversion class is organized into regions according to what data type a method operates on and maybe a user control class
Like any other tool, regions can be misused. The example Jeff cites is just such a misuse. I would guess it resulted from a source code template imposed by the local programming style. You've probably seen this before: lots of block comments (and regions in this case) with "fill-in-the-blank" spots, most of which are left blank. When used properly regions help in the middle ground, when a class is large enough that some meta-organization beyond the methods themselves is useful. I tend to organize regions conceptually: initialization/termination, fundamental properties, public operations, internals. If you have regions wrapping groups of regions (I've seen this on occasion), then that's an indication some serious refactoring is in order.
Software Zen:
delete this; -
I was just searching for a way to collapse LI tags in the Visual Studio editor without having to manually right click it and select "collapse tag" when I got distracted and read Coding Horror: The Problem with Code Folding. I am a big fan of code folding, and here are some points Jeff makes that I disagree with:
- "I can't see anything!" Actually, you can. You can see the first line of whatever is being folded. In the case of regions, you can see the name of the region. When I am doing web development, I tend to wrap code into regions like "Event Handlers" and "Private Methods". If I want to get a feel for how the program flows, I go straight to "Event Handlers" and look for something that looks like the page load event handler (or init, or what have you). Or if there are constructors, I'll look there first. If I just want to see what properties are available in a user control, I'll go to "Properties" (and since the properties are folded, I can ignore their implementation). I find hiding stuff I don't need to see speeds this process up.
- "Folding directives are glorified comments. Why, exactly, are we writing code to accomodate the editor?" Comments are good. Regions are like comments with a bonus feature (folding a region of code that doesn't otherwise get folded). That's not a bad thing. And we're not accomodating the editor... we're accomodating ourselves and other developers who will come in later to see nicely organized code.
- "Folding is used to sweep code under the rung. Folding is used to mask excessive length." No doubt, when it's used wrong. Just don't use it wrong. Simples. Still, there is some value in hiding information that you don't need (it distracts you less and frees your mind to think of what you are trying to focus on).
- "Folding can hide deficiencies in your editor." From another perspective, it replaces a feature seen in other editors. Sometimes I may want to put all my methods into a "Methods" region. Or maybe I'll put them into "Public Methods" and "Private Methods" regions. Or maybe I'll put event handler methods into "Event Handlers". And so on. Relying on an editor to group these sections automatically may be less flexible and so less useful than if a developer were to choose the regions himself or herself. Perhaps a conversion class is organized into regions according to what data type a method operates on and maybe a user control class
I like regions, but seldom use them. I normally use them to help me arrange existing code to better understand it.
-
AspDotNetDev wrote:
Folding is used to sweep code under the rung
I hope he means rug, I'd hate to have to carry a ladder to work. I'm a boring class per file kind of guy but I work on a pretty big c++ code base so the granularity of header files and their use can have a big impact on build times. I thought the regions were pretty cool in c#, what I disliked was the partial keyword and classes spread across multiple files.
_Josh_ wrote:
the partial keyword
I'm rather partial to it myself. I can write a Data Access Layer with separate files for each table. They give us back what C++ already had. On the other hand, I don't agree with needing a keyword, all classes should be partial automatically.
-
I was just searching for a way to collapse LI tags in the Visual Studio editor without having to manually right click it and select "collapse tag" when I got distracted and read Coding Horror: The Problem with Code Folding. I am a big fan of code folding, and here are some points Jeff makes that I disagree with:
- "I can't see anything!" Actually, you can. You can see the first line of whatever is being folded. In the case of regions, you can see the name of the region. When I am doing web development, I tend to wrap code into regions like "Event Handlers" and "Private Methods". If I want to get a feel for how the program flows, I go straight to "Event Handlers" and look for something that looks like the page load event handler (or init, or what have you). Or if there are constructors, I'll look there first. If I just want to see what properties are available in a user control, I'll go to "Properties" (and since the properties are folded, I can ignore their implementation). I find hiding stuff I don't need to see speeds this process up.
- "Folding directives are glorified comments. Why, exactly, are we writing code to accomodate the editor?" Comments are good. Regions are like comments with a bonus feature (folding a region of code that doesn't otherwise get folded). That's not a bad thing. And we're not accomodating the editor... we're accomodating ourselves and other developers who will come in later to see nicely organized code.
- "Folding is used to sweep code under the rung. Folding is used to mask excessive length." No doubt, when it's used wrong. Just don't use it wrong. Simples. Still, there is some value in hiding information that you don't need (it distracts you less and frees your mind to think of what you are trying to focus on).
- "Folding can hide deficiencies in your editor." From another perspective, it replaces a feature seen in other editors. Sometimes I may want to put all my methods into a "Methods" region. Or maybe I'll put them into "Public Methods" and "Private Methods" regions. Or maybe I'll put event handler methods into "Event Handlers". And so on. Relying on an editor to group these sections automatically may be less flexible and so less useful than if a developer were to choose the regions himself or herself. Perhaps a conversion class is organized into regions according to what data type a method operates on and maybe a user control class
+5 here too. when playing w/ C# in visual studio express and saw folding (about 5 years ago) i had to get a text editor w/ folding (settled on JEdit). The IBM Mainframe ISPF editor has an 'exclude line' feature for hiding what is currently noise, but lines must be hidden manually. So with Jedit set as 'fold per indent' all my todo lists look like Python scripts.
-
I was just searching for a way to collapse LI tags in the Visual Studio editor without having to manually right click it and select "collapse tag" when I got distracted and read Coding Horror: The Problem with Code Folding. I am a big fan of code folding, and here are some points Jeff makes that I disagree with:
- "I can't see anything!" Actually, you can. You can see the first line of whatever is being folded. In the case of regions, you can see the name of the region. When I am doing web development, I tend to wrap code into regions like "Event Handlers" and "Private Methods". If I want to get a feel for how the program flows, I go straight to "Event Handlers" and look for something that looks like the page load event handler (or init, or what have you). Or if there are constructors, I'll look there first. If I just want to see what properties are available in a user control, I'll go to "Properties" (and since the properties are folded, I can ignore their implementation). I find hiding stuff I don't need to see speeds this process up.
- "Folding directives are glorified comments. Why, exactly, are we writing code to accomodate the editor?" Comments are good. Regions are like comments with a bonus feature (folding a region of code that doesn't otherwise get folded). That's not a bad thing. And we're not accomodating the editor... we're accomodating ourselves and other developers who will come in later to see nicely organized code.
- "Folding is used to sweep code under the rung. Folding is used to mask excessive length." No doubt, when it's used wrong. Just don't use it wrong. Simples. Still, there is some value in hiding information that you don't need (it distracts you less and frees your mind to think of what you are trying to focus on).
- "Folding can hide deficiencies in your editor." From another perspective, it replaces a feature seen in other editors. Sometimes I may want to put all my methods into a "Methods" region. Or maybe I'll put them into "Public Methods" and "Private Methods" regions. Or maybe I'll put event handler methods into "Event Handlers". And so on. Relying on an editor to group these sections automatically may be less flexible and so less useful than if a developer were to choose the regions himself or herself. Perhaps a conversion class is organized into regions according to what data type a method operates on and maybe a user control class
Having had to work on a codebase written by others using regions extensively, I can say with some certainty that they make it a pain in the arse to navigate through the code and find out what is happening. And if your file is long enough that you think you need them, there's probably some refactoring to be done – it's very easy to use regions to 'tidy up' your code and find that you just keep adding things because you never get the 'oh my I'm doing a lot of scrolling, time to refactor' reaction. Being able to roll up methods and classes is nice (though I never do that either, I use the method selector or page up/down to navigate files), but I find that regions just hide things,
-
Having had to work on a codebase written by others using regions extensively, I can say with some certainty that they make it a pain in the arse to navigate through the code and find out what is happening. And if your file is long enough that you think you need them, there's probably some refactoring to be done – it's very easy to use regions to 'tidy up' your code and find that you just keep adding things because you never get the 'oh my I'm doing a lot of scrolling, time to refactor' reaction. Being able to roll up methods and classes is nice (though I never do that either, I use the method selector or page up/down to navigate files), but I find that regions just hide things,
BobJanova wrote:
there's probably some refactoring to be done
Really? Just keep in mind that there are classes which do a little more than pass around data from and to the database. Not everything is a web application. It's not really fair to suggest that somebody is probably sloppy just because he needs larger classes and needs to organize them a bit more.
BobJanova wrote:
but I find that regions just hide things,
That's the idea. If you have dozens of members, properties, methods, events or whatever it's nice to have a way to make those things which you don't care about at the moment disappear. For example, in my control base class I mentioned before, I may want to see everything what has to do with rendering, and not the stuff for processing input.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse. -
I was just searching for a way to collapse LI tags in the Visual Studio editor without having to manually right click it and select "collapse tag" when I got distracted and read Coding Horror: The Problem with Code Folding. I am a big fan of code folding, and here are some points Jeff makes that I disagree with:
- "I can't see anything!" Actually, you can. You can see the first line of whatever is being folded. In the case of regions, you can see the name of the region. When I am doing web development, I tend to wrap code into regions like "Event Handlers" and "Private Methods". If I want to get a feel for how the program flows, I go straight to "Event Handlers" and look for something that looks like the page load event handler (or init, or what have you). Or if there are constructors, I'll look there first. If I just want to see what properties are available in a user control, I'll go to "Properties" (and since the properties are folded, I can ignore their implementation). I find hiding stuff I don't need to see speeds this process up.
- "Folding directives are glorified comments. Why, exactly, are we writing code to accomodate the editor?" Comments are good. Regions are like comments with a bonus feature (folding a region of code that doesn't otherwise get folded). That's not a bad thing. And we're not accomodating the editor... we're accomodating ourselves and other developers who will come in later to see nicely organized code.
- "Folding is used to sweep code under the rung. Folding is used to mask excessive length." No doubt, when it's used wrong. Just don't use it wrong. Simples. Still, there is some value in hiding information that you don't need (it distracts you less and frees your mind to think of what you are trying to focus on).
- "Folding can hide deficiencies in your editor." From another perspective, it replaces a feature seen in other editors. Sometimes I may want to put all my methods into a "Methods" region. Or maybe I'll put them into "Public Methods" and "Private Methods" regions. Or maybe I'll put event handler methods into "Event Handlers". And so on. Relying on an editor to group these sections automatically may be less flexible and so less useful than if a developer were to choose the regions himself or herself. Perhaps a conversion class is organized into regions according to what data type a method operates on and maybe a user control class
Regions are a vital part of readable code... I usually split them up into control events: #Region [control name] Events .. Then the allmighty allimportant underused keyboard shortcut: Ctrl+M Ctrl+O.
-
Regions are a vital part of readable code... I usually split them up into control events: #Region [control name] Events .. Then the allmighty allimportant underused keyboard shortcut: Ctrl+M Ctrl+O.
..And BTW... I saw some screenshots of the next Visual Studio, and it seems that you can see all your functions, routines, regions(?), on the solution explorer. Don't know if any current versions have this. I'm still on VS2008 sp1... Can't wait to get an upgrade.
-
I was just searching for a way to collapse LI tags in the Visual Studio editor without having to manually right click it and select "collapse tag" when I got distracted and read Coding Horror: The Problem with Code Folding. I am a big fan of code folding, and here are some points Jeff makes that I disagree with:
- "I can't see anything!" Actually, you can. You can see the first line of whatever is being folded. In the case of regions, you can see the name of the region. When I am doing web development, I tend to wrap code into regions like "Event Handlers" and "Private Methods". If I want to get a feel for how the program flows, I go straight to "Event Handlers" and look for something that looks like the page load event handler (or init, or what have you). Or if there are constructors, I'll look there first. If I just want to see what properties are available in a user control, I'll go to "Properties" (and since the properties are folded, I can ignore their implementation). I find hiding stuff I don't need to see speeds this process up.
- "Folding directives are glorified comments. Why, exactly, are we writing code to accomodate the editor?" Comments are good. Regions are like comments with a bonus feature (folding a region of code that doesn't otherwise get folded). That's not a bad thing. And we're not accomodating the editor... we're accomodating ourselves and other developers who will come in later to see nicely organized code.
- "Folding is used to sweep code under the rung. Folding is used to mask excessive length." No doubt, when it's used wrong. Just don't use it wrong. Simples. Still, there is some value in hiding information that you don't need (it distracts you less and frees your mind to think of what you are trying to focus on).
- "Folding can hide deficiencies in your editor." From another perspective, it replaces a feature seen in other editors. Sometimes I may want to put all my methods into a "Methods" region. Or maybe I'll put them into "Public Methods" and "Private Methods" regions. Or maybe I'll put event handler methods into "Event Handlers". And so on. Relying on an editor to group these sections automatically may be less flexible and so less useful than if a developer were to choose the regions himself or herself. Perhaps a conversion class is organized into regions according to what data type a method operates on and maybe a user control class
I love code folding. We have a complicated Web application with hundreds of pages that we are moving to a common .NET architecture, with base classes for different screen types (Criteria, List or Detail) . My developers all put the code in the same sections, so it makes it very helpful for debugging. The larger the development team the more benefit realized from standardization.
-
I was just searching for a way to collapse LI tags in the Visual Studio editor without having to manually right click it and select "collapse tag" when I got distracted and read Coding Horror: The Problem with Code Folding. I am a big fan of code folding, and here are some points Jeff makes that I disagree with:
- "I can't see anything!" Actually, you can. You can see the first line of whatever is being folded. In the case of regions, you can see the name of the region. When I am doing web development, I tend to wrap code into regions like "Event Handlers" and "Private Methods". If I want to get a feel for how the program flows, I go straight to "Event Handlers" and look for something that looks like the page load event handler (or init, or what have you). Or if there are constructors, I'll look there first. If I just want to see what properties are available in a user control, I'll go to "Properties" (and since the properties are folded, I can ignore their implementation). I find hiding stuff I don't need to see speeds this process up.
- "Folding directives are glorified comments. Why, exactly, are we writing code to accomodate the editor?" Comments are good. Regions are like comments with a bonus feature (folding a region of code that doesn't otherwise get folded). That's not a bad thing. And we're not accomodating the editor... we're accomodating ourselves and other developers who will come in later to see nicely organized code.
- "Folding is used to sweep code under the rung. Folding is used to mask excessive length." No doubt, when it's used wrong. Just don't use it wrong. Simples. Still, there is some value in hiding information that you don't need (it distracts you less and frees your mind to think of what you are trying to focus on).
- "Folding can hide deficiencies in your editor." From another perspective, it replaces a feature seen in other editors. Sometimes I may want to put all my methods into a "Methods" region. Or maybe I'll put them into "Public Methods" and "Private Methods" regions. Or maybe I'll put event handler methods into "Event Handlers". And so on. Relying on an editor to group these sections automatically may be less flexible and so less useful than if a developer were to choose the regions himself or herself. Perhaps a conversion class is organized into regions according to what data type a method operates on and maybe a user control class
Regions suck, pure and simple. Except for a few rare exceptions, if I see a lot of regions, it's usually because the class contains too much and needs to be refactored. If your code is well organized, it's easy to find exactly what you're looking for in 2-3 seconds or less. Put all your private field declarations, your internals, your public methods, public properties and constructors in the same order, and you will be able to find everything really quickly. This is my preferred order: Constructors Public properties Public methods Protected properties & methods Internal properties & methods Private methods Private fields Having ReSharper helps a lot too, if you're a .NET developer. Ctrl-Alt-F shows you all your declarations in a nice window with the ability to drag things around. Why create housekeeping tasks with keeping regions neat and tidy? They don't add anything you can't get by just keeping your classes to a reasonable size and being a little bit organized.
-
I was just searching for a way to collapse LI tags in the Visual Studio editor without having to manually right click it and select "collapse tag" when I got distracted and read Coding Horror: The Problem with Code Folding. I am a big fan of code folding, and here are some points Jeff makes that I disagree with:
- "I can't see anything!" Actually, you can. You can see the first line of whatever is being folded. In the case of regions, you can see the name of the region. When I am doing web development, I tend to wrap code into regions like "Event Handlers" and "Private Methods". If I want to get a feel for how the program flows, I go straight to "Event Handlers" and look for something that looks like the page load event handler (or init, or what have you). Or if there are constructors, I'll look there first. If I just want to see what properties are available in a user control, I'll go to "Properties" (and since the properties are folded, I can ignore their implementation). I find hiding stuff I don't need to see speeds this process up.
- "Folding directives are glorified comments. Why, exactly, are we writing code to accomodate the editor?" Comments are good. Regions are like comments with a bonus feature (folding a region of code that doesn't otherwise get folded). That's not a bad thing. And we're not accomodating the editor... we're accomodating ourselves and other developers who will come in later to see nicely organized code.
- "Folding is used to sweep code under the rung. Folding is used to mask excessive length." No doubt, when it's used wrong. Just don't use it wrong. Simples. Still, there is some value in hiding information that you don't need (it distracts you less and frees your mind to think of what you are trying to focus on).
- "Folding can hide deficiencies in your editor." From another perspective, it replaces a feature seen in other editors. Sometimes I may want to put all my methods into a "Methods" region. Or maybe I'll put them into "Public Methods" and "Private Methods" regions. Or maybe I'll put event handler methods into "Event Handlers". And so on. Relying on an editor to group these sections automatically may be less flexible and so less useful than if a developer were to choose the regions himself or herself. Perhaps a conversion class is organized into regions according to what data type a method operates on and maybe a user control class
My biggest complaint of code folding, whether from regions or class level, is that I can't fold from the bottom. In order to fold, you have to go to the top of a region and click the button. When will Visual Studio allow me to fold from the end of a region or class? This would save very tedious scrolling!!! Hogan
-
Regions suck, pure and simple. Except for a few rare exceptions, if I see a lot of regions, it's usually because the class contains too much and needs to be refactored. If your code is well organized, it's easy to find exactly what you're looking for in 2-3 seconds or less. Put all your private field declarations, your internals, your public methods, public properties and constructors in the same order, and you will be able to find everything really quickly. This is my preferred order: Constructors Public properties Public methods Protected properties & methods Internal properties & methods Private methods Private fields Having ReSharper helps a lot too, if you're a .NET developer. Ctrl-Alt-F shows you all your declarations in a nice window with the ability to drag things around. Why create housekeeping tasks with keeping regions neat and tidy? They don't add anything you can't get by just keeping your classes to a reasonable size and being a little bit organized.
-
I was just searching for a way to collapse LI tags in the Visual Studio editor without having to manually right click it and select "collapse tag" when I got distracted and read Coding Horror: The Problem with Code Folding. I am a big fan of code folding, and here are some points Jeff makes that I disagree with:
- "I can't see anything!" Actually, you can. You can see the first line of whatever is being folded. In the case of regions, you can see the name of the region. When I am doing web development, I tend to wrap code into regions like "Event Handlers" and "Private Methods". If I want to get a feel for how the program flows, I go straight to "Event Handlers" and look for something that looks like the page load event handler (or init, or what have you). Or if there are constructors, I'll look there first. If I just want to see what properties are available in a user control, I'll go to "Properties" (and since the properties are folded, I can ignore their implementation). I find hiding stuff I don't need to see speeds this process up.
- "Folding directives are glorified comments. Why, exactly, are we writing code to accomodate the editor?" Comments are good. Regions are like comments with a bonus feature (folding a region of code that doesn't otherwise get folded). That's not a bad thing. And we're not accomodating the editor... we're accomodating ourselves and other developers who will come in later to see nicely organized code.
- "Folding is used to sweep code under the rung. Folding is used to mask excessive length." No doubt, when it's used wrong. Just don't use it wrong. Simples. Still, there is some value in hiding information that you don't need (it distracts you less and frees your mind to think of what you are trying to focus on).
- "Folding can hide deficiencies in your editor." From another perspective, it replaces a feature seen in other editors. Sometimes I may want to put all my methods into a "Methods" region. Or maybe I'll put them into "Public Methods" and "Private Methods" regions. Or maybe I'll put event handler methods into "Event Handlers". And so on. Relying on an editor to group these sections automatically may be less flexible and so less useful than if a developer were to choose the regions himself or herself. Perhaps a conversion class is organized into regions according to what data type a method operates on and maybe a user control class
I'm ok with Regions when they're used to group functions, methods or properties. Regions within a method or function should be disallowed. Far too many programmers use regions to denote what should be a separate function.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun -
I was just searching for a way to collapse LI tags in the Visual Studio editor without having to manually right click it and select "collapse tag" when I got distracted and read Coding Horror: The Problem with Code Folding. I am a big fan of code folding, and here are some points Jeff makes that I disagree with:
- "I can't see anything!" Actually, you can. You can see the first line of whatever is being folded. In the case of regions, you can see the name of the region. When I am doing web development, I tend to wrap code into regions like "Event Handlers" and "Private Methods". If I want to get a feel for how the program flows, I go straight to "Event Handlers" and look for something that looks like the page load event handler (or init, or what have you). Or if there are constructors, I'll look there first. If I just want to see what properties are available in a user control, I'll go to "Properties" (and since the properties are folded, I can ignore their implementation). I find hiding stuff I don't need to see speeds this process up.
- "Folding directives are glorified comments. Why, exactly, are we writing code to accomodate the editor?" Comments are good. Regions are like comments with a bonus feature (folding a region of code that doesn't otherwise get folded). That's not a bad thing. And we're not accomodating the editor... we're accomodating ourselves and other developers who will come in later to see nicely organized code.
- "Folding is used to sweep code under the rung. Folding is used to mask excessive length." No doubt, when it's used wrong. Just don't use it wrong. Simples. Still, there is some value in hiding information that you don't need (it distracts you less and frees your mind to think of what you are trying to focus on).
- "Folding can hide deficiencies in your editor." From another perspective, it replaces a feature seen in other editors. Sometimes I may want to put all my methods into a "Methods" region. Or maybe I'll put them into "Public Methods" and "Private Methods" regions. Or maybe I'll put event handler methods into "Event Handlers". And so on. Relying on an editor to group these sections automatically may be less flexible and so less useful than if a developer were to choose the regions himself or herself. Perhaps a conversion class is organized into regions according to what data type a method operates on and maybe a user control class
AspDotNetDev wrote:
What's your take on code folding, especially with respect to regions?
Don't like regions, everybody uses them in a different way and the different groupings that some teams want are merely timewasters. I first came across the concept in Amos BASIC, and I loved it; it was a huge improvement, but it didn't work with regions. Amos collapsed them at the method-level, and if you collapsed them all, you'd be looking at the signatures - comparable to Delphi's interface part of the unit. It worked very well, and I haven't come across a decent code-folding feature since then.
Bastard Programmer from Hell :suss:
-
I was just searching for a way to collapse LI tags in the Visual Studio editor without having to manually right click it and select "collapse tag" when I got distracted and read Coding Horror: The Problem with Code Folding. I am a big fan of code folding, and here are some points Jeff makes that I disagree with:
- "I can't see anything!" Actually, you can. You can see the first line of whatever is being folded. In the case of regions, you can see the name of the region. When I am doing web development, I tend to wrap code into regions like "Event Handlers" and "Private Methods". If I want to get a feel for how the program flows, I go straight to "Event Handlers" and look for something that looks like the page load event handler (or init, or what have you). Or if there are constructors, I'll look there first. If I just want to see what properties are available in a user control, I'll go to "Properties" (and since the properties are folded, I can ignore their implementation). I find hiding stuff I don't need to see speeds this process up.
- "Folding directives are glorified comments. Why, exactly, are we writing code to accomodate the editor?" Comments are good. Regions are like comments with a bonus feature (folding a region of code that doesn't otherwise get folded). That's not a bad thing. And we're not accomodating the editor... we're accomodating ourselves and other developers who will come in later to see nicely organized code.
- "Folding is used to sweep code under the rung. Folding is used to mask excessive length." No doubt, when it's used wrong. Just don't use it wrong. Simples. Still, there is some value in hiding information that you don't need (it distracts you less and frees your mind to think of what you are trying to focus on).
- "Folding can hide deficiencies in your editor." From another perspective, it replaces a feature seen in other editors. Sometimes I may want to put all my methods into a "Methods" region. Or maybe I'll put them into "Public Methods" and "Private Methods" regions. Or maybe I'll put event handler methods into "Event Handlers". And so on. Relying on an editor to group these sections automatically may be less flexible and so less useful than if a developer were to choose the regions himself or herself. Perhaps a conversion class is organized into regions according to what data type a method operates on and maybe a user control class
I use regions extensively around every method/property. Keeps my classes neat and easy to glance through. (see example below)
#region public string Name
/// /// Lorem ipsum...
///
public string Name {
get {return _name;}
set {_name=value;}
}
private string _name="default";
#endregionI have written macros that creates/updates the regions and for folding/unfolding the current or all regions in a class. Just press Ctrl+d when cursor is in/on a method/property and you have the correct region and documentation for the member as well... See article about macros here[^] or download the latest version[^].