Re: Generating Source Code :: Comments

>David Chase wrote
>I also recall that keeping track of comments, and placing them
>nicely, is a big problem.


I appologize in advance if these ideas have already been adressed in
the book you refered to (Knuth), but I don't have that book handy and
I wanted to bounce this idea back as quickly as possible to let the
group run with it.


There would of course be no way to systematically format comments for
all source code, because their content, meanings, and associations are
in no way specified by the language (unlike every other contruct in
the language). BUT, most people DO use their own comment formatting
rules, because it would be very hard to make sense of comments with no
order or clear visual relation to them. So here is my idea:


Tie the commment construct to either the preceeding or following syntactic
element based on both what the elements are and what the input looked liked.
Example of a potential rules:
Comments that share lines with other constructs -
        1. Any comment (// or /**/) that is on the same line as another
construct should be tied to the end of the other construct.
        2. Any (/**/) comment that begins a line that also contains another
construct should be tied to the beginning of that construct.
        3. Not sure what to do about comments wedged between 2 constructs on
the same line, but it could be evident be obvious in certain situations
based on white space or on the nature of the 2 surrounding constructs.
Comments(or comment blocks) that are on their own line -
        4. Any comment block that resides on a line or lines by itself would
be analized by the blank lines around it: a)blank line above - attact to
follwing construct, b)blank line below - attach to above construct,
c)engulfed in white space - make it a free floating comment (preserve the
white space gap in pretty printouts), d)no blank lines - must resort to
rules of preference for each construct(see below).


As you can see, there are some cases where the rules are quite
obvious, and others that are actually only valid because most
programmers follow some standard conventions. One such example would
be the evaluation of comments that are equadistant from two constructs
(3 and 4d). One example of standard practice is that if the two
constructs are function bodies or prototypes, the comment probably
belongs to the construct that follows it (because we almost always
comment BEFORE functions).


Well...there's my 2.5 cents on the matter.


Keith McAfee
e-mail: rationalmonkey27@yahoo.com
[I've seen systems that do that. If you have programmers that format
comments in a reasonably systematic way, it works. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.