the news at 10

"You'd need a bulldozer to start refactoring it." Such a bulldozer does in fact exist. It's the Leo outliner and you can read about it at http://personalpages.tds.net/~edream/front.html.

It's a free outliner that lets your write programs in outline form, with arbitrary amounts of complexity pushed down into sub nodes and represented by just a descriptive label at higher levels. It can then generate plain text files from your outline suitable for input to a compiler or interpreter.

I use it for any new code I write and I also like it for understanding someone else's code. I start by making each of their files into one node in a Leo outline. Then I'll split out each of the functions or subroutines into their own nodes. All the global variable declarations get their own node too.

This already starts to give me an overview of what I'm looking at. Then for each of those nodes I'll go through and break it down some more. Anywhere I see a big, hairy if-then-else block, I'll take the if-true case and the if-false case and make them into their own subnodes. In this way I can transform the program into a hierachical tree where all the higher nodes look almost like pseudocode because I've replaced all the large blocks of code by little tags that refer to subnodes and that have descriptive names describing what the hidden code does.

I like to get it to the point where no single node in my outline has more than a dozen or so lines in it. If you're smarter than I am and have a higher tolerance for complexity you could keep your nodes bigger or, if that part of the code is working well, just defer breaking it down until you need to understand it better.

Note: everything I've described so far does not change in any way the flat text file that gets fed to the compiler or interpreter (except for added comments that Leo inserts to keep track of things so it can read the file back into your outline and capture any changes you may have made to it in its flat text form). It's strictly for you to understand it better.

Then when you're ready to do some refactoring it makes things much easier than editing a text file. For example, I like to find any subroutines that are only called from one place in the code. When I do, I move the node that holds the subroutine so it becomes a child of the node that holds the code that has the one place it's called from.

For the remaining subroutines I like to try to group them together by function under a new node with a name that describes what they have in common. Obviously, nodes that end up grouped this way are prime candidates for refactoring.

Well, 'nuff said. Go read the web page if you're interested. I certainly do consider Leo a bulldozer for refactoring or for coding in general. It's also great for just organzing other information that has nothing to do with code at all -- a single outline can freely mix nodes that are just your notes with other nodes that generate external files containing code (or html or LaTeX etc.)

Investigating now...

Leo's also a fabulous way to organize your URL bookmarks. You can make so-called @url nodes that, when double clicked, pop up a web browser and show you the page. I, of course, have a node called "blogs" with my favorite blogs listed so I can just click to see any one of them. Also, I find that almost kind of research project these days benefits from being able to keep track of URLs along with your other notes. These URLs can, by the way, begin with file:// so it's also a great way to pull together and organize your local files.