Code Browser As Excuse For Mess

Some languages or techniques seem to rely on a code-browser of some kind in order to manage something. Maybe this is just the future and "Paper is Dead", but paper still seems better for intense study and marking up with pencils and hiliters, etc. Paper is easier on my eyes than monitors, but perhaps others differ. I like code browsers also, but is it a mistake to rely on techniques that almost must have a code browser to be usable?

Possible targets of such criticism:

ShortMethods
Lisp parentheses
Python whitespace

Formerly from above: (try dealing with block indentation in notepad)

I deal with Python's whitespace in Vim just fine. Vim offers no overt functionality I'm aware of to deal with its whitespace. Still, I have zero problems working with it.

The use of ShortMethods, in fact, enables whitespace significance; methods longer than roughly 20 lines should be refactored into smaller methods, so that you can keep a single method's complete context on-screen at once. Unless you are using a TRS-80 for a terminal, the 20 line length threshold should be adequate for 99.999% of the Python hacking community.

For LispLanguage, I'd envision you don't want a code browser, so much as a smarter editor. Any editor which can script keyboard events should be sufficient to detect when "(" is typed, so that it can automatically insert ")" on your behalf. Notepad clearly lacks this support; however, Notepad's audience primarily seeks only to tweak .INI files.

Thus, Notepad, while a text editor, proves inappropriate as a tool for developing software, just as a flathead screwdriver proves inappropriate for driving philips-head screws. It can be done, but having a real philips-head screwdriver enables greater productivity. --SamuelFalvo?

CodeBrowsers? are simply tools to deal with highly complex software. The complexity may arise from bad coding habits, but it may also arise from ten million lines of enterprise software code.

As pointed out in TheSocialLifeOfPaper, paper is best suited to transient and impermanent information. This clearly has nothing to do with "intense study". Further, you have to rely on code browsers for the simple reason that code is electronic. And this is a Good Thing since electronic data is best suited to long-term archival, retrieval and manipulation.

If code browsers make "intense study" difficult, especially seeing the big picture in a large project, it's because code browsers are broken. As pointed out in ObjectBrowser, VisualWorks' code browser lacks even the simple visitation stack (back/forward buttons) of web browsers. And as DougEngelbart pointed out, an outline editor is different from and superior to a mere text editor. Code browsers lack any concept of outlines.

Code browsers are not going to offer much help in decyphering complex or messy algorithms. For those, I get a print-out and sit down at a table with pencils and draw lines and squiggles as I mentally trace through the code.

Compare MessAsExcuseForNeglectingCodeBrowsers

CategorySourceManagement