jfr@locus.com (Jon Rosen) (12/29/90)
I want to propose an idea (which I am sure might have already been proposed previously, but what the hey, I haven't seen it before)... I was reading a post in comp.emacs on yet another style of indentation for C++ which talked about the issue of commenting every line of source code and how indentation eats up real estate in the program... This has always been a problem... However it struck me as weird that we continue to allow archaic physical concepts and restrictions that are no longer even remotely valid to dictate the way we do things... By this, I mean that we continue to use the old 80-column card standard (and its 80-column wide glass-titty metaphor) to restrict our thinking on comments, indentation and programming style... Food for thought: The "sticky note" concept (those little yellow things from 3M) is a superb documentation concept and has already made its way into the computer arena in the form of add-in products for things like 1-2-3, Excel, Microsoft Word, etc. In these add-ins, the user can "open up" a "sticky note" anywhere in a file and type in comments about the spreadsheet cell, paragraph, chart, etc. This seems like a wonderful concept to extend to programs... The "sticky notes" are kept hidden but can reappear at the click of a function key or mouse button... Of course, we would need several things, not the least of which would be new types of file support, editor support and possibly compiler support... This would also tend to limit the portability of a program commented in this fashion... But the productivity increase might be enough to offset these penalties... Anyway, any comments? Jon Rosen
tmb@ai.mit.edu (Thomas M. Breuel) (12/29/90)
In article <20903@oolong.la.locus.com> jfr@locus.com (Jon Rosen) writes:
Food for thought: The "sticky note" concept (those little yellow
things from 3M) is a superb documentation concept [...]. In these add-ins,
the user can "open up" a "sticky note" anywhere in a file [...]
The "sticky notes" are kept hidden but can reappear at the click of
a function key or mouse button...
Of course, we would need several things, not the least of which would
be new types of file support, editor support and possibly compiler
support... This would also tend to limit the portability of a program
commented in this fashion... But the productivity increase might
be enough to offset these penalties...
Anyway, any comments?
You can get virtually the same effect by selectively hiding
and selecting code in GNU Emacs. Take a look at "hideif.el"
in the Emacs distribution. You could extend hideif to special
comment format (e.g., you might enclose "hideable" comments with
/*[ ... ]*/). The advantages of such an approach would be that
it does not require new file formats or tools, and that it
requires only a minimum of hacking.brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (01/01/91)
Isn't this normally called ``hypertext''? A document may contain references to other files. The references are displayed as single, compact symbols. When the user somehow activates a symbol, the corresponding file is displayed. Files may be displayed by programs other than the text editor, of course; those other programs support the same conventions. I wouldn't like to program with hypertext because my printer can't deal with sticky yellow notes. In article <20903@oolong.la.locus.com> jfr@locus.com (Jon Rosen) writes: > Of course, we would need several things, not the least of which would > be new types of file support, editor support and possibly compiler > support... Nah, only the editor has to change. You might, for instance, have /*FILE:foo*/ be a reference to file foo. It would be displayed as a dot or inverse star or whatever. When the user selects it, foo pops up. > This would also tend to limit the portability of a program > commented in this fashion... Why? > But the productivity increase might > be enough to offset these penalties... I doubt it. ---Dan
asylvain@felix.UUCP (Alvin "the Chipmunk" Sylvain) (01/04/91)
In article <20903@oolong.la.locus.com> jfr@locus.com (Jon Rosen) writes: > I want to propose an idea (which I am sure might have already been > proposed previously, but what the hey, I haven't seen it before)... > > I was reading a post in comp.emacs on yet another style of indentation > for C++ which talked about the issue of commenting every line of > source code and how indentation eats up real estate in the program... I want to propose another idea ... if your indentation is eating that much real estate, maybe it's an indication that the code is not modular enough. Rule of thumb ... if your (admitedly limited) 80 columns have had a third or half of it's left margin chewed up with nested constructs, it's probably well past time to break something into a subroutine. [...] > By this, I mean that we continue to use the old 80-column card > standard (and its 80-column wide glass-titty metaphor) to restrict > our thinking on comments, indentation and programming style... [...] Lest we forget ... that limited 80-column wide card is already too wide to be displayed on a standard 8 1/2 x 11 sheet of paper with standard 1 inch margin using standard 12 pitch type. We probably still want someone who's used to this limitation (99.9% of the reading population) to be able to read and understand the stuff. The problem is alleviated somewhat using troff/Macintosh/Postscript styled type-setting, but it's still remains true that it's a good idea to cut down a bit on the size of things like lines, indentations, vertical stretches of uninterrupted code, and explanatory sentences so they can be understood. That last sentence is a perfect example of breaking my own rule. Now, I'll admit that formatting code and comments so that they are easily readable by mere humans is more work. Maybe someone will invent a reformatter that does it automatically to *everybody's* satisfaction. Until then, you're just stuck with a tiresome task that happens to be part of your job. Damn shame, isn't it? -- asylvain@felix.UUCP (Alvin "the Chipmunk" Sylvain) ========================= Opinions are Mine, Typos belong to /usr/ucb/vi "We're sorry, but the reality you have dialed is no longer in service. Please check the value of pi, or see your SysOp for assistance." UUCP: hplabs!felix!asylvain ============================================