Programming with
a dose of satire.
Programming
|
| ||||||||
 |
 |
|||||||
|
Programming |
||||||||
Code Folding - A Solution Looking for a ProblemBy Matt Stephens Code folding is one of those groovy time-saving features that, ultimately, is more trouble than it's worth. Years ago, when I was programming in GFA Basic on my untrusty old Atari ST (GFA Basic was one of the "modern" BASICs that *gasp* didn't use line numbers, and seemed more like Pascal), I used to love the editor's code folding ability. Sometimes my procedural programs would get very large, so code folding was a great way to hide away the method bodies and just see a program as a series of high-level "DoThis, DoThat" statements. I'd never seen anything quite like it, and haven't seen the same ability since, until in recent IDE releases for both Java and DotNet. The thing is, looking at code folding now, I find it annoying at best. So, naturally, I avoid it. Why the change of heart? Code folding back in the Atari ST/GFA Basic days was a godsend because BASIC didn't have even a hint of any object-oriented constructs. So I couldn't break code into different classes, encapsulate away the details and just operate on the interfaces. Code folding allowed me to break the code down in a different way, so that I could see the wood for the trees. What I only realised afterwards was that code folding was encouraging me to write bigger and bigger methods, and not bother to break them up into smaller bite-sized methods. The result was that I too often ended up with "write-once-maintain-never" programs with big monolithic methods. Code folding has begun to reappear in modern IDEs - Visual Studio .Net, Eclipse, and now NetBeans 3.6. This is odd, because the problems that code folding originally addressed have since been eradicated in other, much neater, less transient ways - namely, object-oriented design. If you're staring at your program and can't see the wood for the trees, code folding is the wrong answer. The answer is to structure your program better; encapsulate the details into different classes, use interfaces, small methods, and so on. The other thing about code folding is that you end up wasting a lot of time folding methods, unfolding them, when this isn't really getting you anywhere. It feels like you're doing work because you're actively clicking away; but you're not actually making any progress. It's like trying to rearrange the contents of a cupboard by constantly opening and closing the cupboard doors. So if code folding can promote bad coding habits (even at a subconscious level), should it be included? It's a bit like reinstating the goto statement. Plenty of people love "goto" and insist that it never made them write badly structured code, but still… One area where code folding is useful is in hiding JavaDoc. Whether you're writing an API that needs pages of JavaDoc above each class and method, or using XDoclet which makes heavy use of JavaDoc tags, it can be useful to just hide all this stuff away. Another area is, of course, when looking at someone else's code. If there's a bad coder on your team, you might want to use code folding to cut their big monolithic classes down to size while trying to work out what the hell the code is doing. Thinking long-term though, this is propagating the problem. If you're working in a team it might become easier to just fold their code away (sweep it under the carpet) than to tackle the issue head-on, i.e. that someone sitting next to you is putting badly written code into the project. So the problem propagates because there's a "quick & easy" short-term fix. A hack, even. Footnote: This article originated from a weblog posting I made a few weeks back. Thanks to those people who posted comments - your feedback is reflected in this article.
Books About Coding Style and Things Links are to Amazon.com:
Message Forum: Message Index:
The Messages: SillyFolding is very useful when it comes to hiding boring implementation code. The world is not a pure OO paradise in that one must frequently write a dewhackify() method or makethiscrapfit() or the classic noCementBlocksOnMyBowlingLanes(). Microsoft also creates these huge ugly initialization methods that would drive me insane if not folded away. My advice ...fold the crap away and let the rest stay! jc Mon Jan 10 13:25:08 GMT 2005 I completely disagree If folding the code is enough to encourage you to write bad code, the problem isn't the IDE. It's either a matter of hacker's myopia -- out of sight, out of refactoring mind -- or a paralyzing case of design-it-right syndrome. If you have a sequence of logic that works efficiently and can't be reduced or objectified, your brain shouldn't insist on objectifying it anyway. Design optimization is a dish best served on demand, lest time and energy is wasted creating flexibility for elementally rigid systems. This is how embarassments like my company's 500 line "Gender Types" class get architected (since replaced by a nullable IsFemale property). An unfortunate side effect of the push to object orient everything is that some of us have forgotten that procedural code is sometimes just easier to read. It holds no surprises and reduces unwanted side effects. And in these cases I prefer a big, long, grokable procedure that's been properly tuned and pruned to a ballet of interfaces. I have a method that is -- GASP -- several thousand lines long. It is the instantion method for the rest of my application, and it makes up about 80% of the controller object's total line length. I could break it out into various grouped subroutines, but this is where everything is wired together. Dependency is high and the order of operations is crucial. It is much easier for everybody involved with our application's production and maintenance to keep this essential workflow together in one place. I just don't want to see that huge goddamn method every time I open the file to add an Event Handler. Hence, Code Folding helps protects the sanctity of my logic and thus my sanity. dasmb das@dasmegabyte.org Albany, NY, USA Fri Jun 03 20:11:00 BST 2005 |
||||||||
All trademarks and copyrights on this page are owned by their respective owners.
Stories and articles are owned by the original author.
All the rest Copyright © 1998-2008 Matt Stephens. ALL RIGHTS RESERVED.