12/18/2023 0 Comments Visual studio collapse allI'm sure there are sane uses for code folding out there somewhere, but I rarely see them.While SSRS allows drill-down into individual groups in a Tablix, there is no built-in, direct support for an “expand all/collapse all” capability that would allow all groups to be simultaneously expanded or collapsed. I urge developers to write code that doesn't need folding to be readable, clear, and concise. Or at least demanding a smarter code editor. The editor should automatically offer to fold up these common structural blocks for you! I'm continually amazed that programmers spend time doing this scutwork when they could be writing useful code. The presence of so-called "standard" boilerplate regions like "Public Constructors" and "Public Properties" and "Events" is not a feature. Folding can hide deficiencies in your editor.If the code needs the crutch of folding to look organized, it's bad code. Under the cover of folding, you can end up writing long, horrible spaghetti code blocks. The presence of folded code can lull developers into a false sense of what clean code looks like. Folding is used to mask excessive length.Your code should be front and center at all times - exposed to as many programmers' eyes, and as much healing light, as possible. Much worse! Code that hides from you is code that will rot in the most putrescent and painful way possible. Your project is now full of crappy code that you can't see. Got a bunch of boring boilerplate code that makes your eyes water? A slew of ugly, gnarly code that nobody in their right mind wants to look at? Hide it in a region and fold that sucker into oblivion! Problem solved, right? Hardly. Folding is used to sweep code under the rug.And folding is certainly no substitute at all for bona-fide refactoring. Even traditional comments are a better value for your keystroke, because they can be more expressive. Why, exactly, are we writing code to accommodate the editor? It boggles my mind that we'd add significant lines of code to our project that do nothing but offer organizational hints to the editor. It doesn't do any namespacing or scoping. #region has zero meaning to the compiler it's a hint to the editor to allow code folding. Folding directives are glorified comments.I strongly urge you to think about how you're using code folding, because as I see it, there are a lot of downsides: It's not evil, per se, but I feel it is criminally overused in practice and heavily prone to abuse. It's as if they've forgotten what the scroll bar - and incremental search - is for. I daresay being able to see the damn code is more important than having it meticulously segmented into six pointless little named buckets, but apparently a lot of programmers can't get enough of stuffing their code into pointless little named buckets. Here's the really sick part: once you expand the above log4net code there's literally three pages worth of code there! After you strip out all the massive XMLDoc comments and the dozen or so #region directives, you could have had all the code at your fingertips with a minor flick of the mouse wheel, in a simple scrollable layout. And of course there are keyboard shortcuts to deal with the regions:Ĭollapse or expand the block you're currently in. It is possible to configure the Visual Studio IDE to not fold any of the regions when files are opened, but this is the out of box behavior, so that's what most developers will see. Immediately I have a problem: I can't see anything! I have to manually expand those sections to browse any of the code in this class. Here's a random example from the Log4Net project: Any code placed inside that region is, by default, collapsed when you re-open it in the editor. So what is #region? It's a named hint you place in C# or VB.NET code to set a code folding point. I tried to make myself clear in this twitter message: For me, the use of #region is one of those things. If that's the case, try to clear the air and address those strong preferences up front, as early as possible. Still, there are some coding preferences people may feel. It's a very short trip indeed from there to Who Wrote This Crap, and the predictable, inevitable finger-pointing at the foolhardy programmers who came before you begins. I've always been wary of cowboy coders who rolled into an ongoing project on fresh horses and immediately started dictating terms. As they say, when in Rome, do as the Romans do. It promotes team harmony, and more than that, it's just common courtesy. Not everyone has to agree on every miniscule detail of the code, of course, but it's a good idea to dicuss it with your team and decide on overall approaches and philosophy beforehand. When you join a team, it's important to bend your preferences a little to accommodate the generally accepted coding practices of that team.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |