Syntax of Comments (was: language design tradeoffs)

jlg@cochiti.lanl.gov (Jim Giles) writes:
>Inadvertent commenting out of long sequences of code is a common error in
>languages in which the scope of a comment is not constrained to a single
>line. It also can leave valid code behind - again, an error that cannot
>be detected automatically and may be hard to isolate (from experience with
>real users, I can tell you that you can stare at such an improperly
>terminated comment for ages and your mental picture of what's *supposed*
>to be there will prevent you from seeing the problem). And, of course,
>deliberately `commenting out' code is better handled with `ifdefs' or some
>such concept.


I dislike the `ifdef' approach to commenting out code for one very simple
reason --- I can't tell by looking at a piece of code that it is commented
out. I have to look up the next for an `ifdef'. When every commented
line is marked clearly as being commented, then I can concentrate more
locally.


The only arguments that I've ever heard against this approach are "it's
too much work to comment every line" and "block comments are a pain".
This is true if you have a brute simple editor. However, programmers
should be working with an editor that supports regular expressions.


Given such a reasonable editor, to comment out a region of text:


        mark top
        mark bottom
        insert comment marker at beginning of each line in marked region


This procedure is near as easy as inserting the `ifdef' and `endif' lines,
unless you're using cards and have a few `ifdef' cards lying around. :-)


Blocks are a little more difficult. However, emacs supports reformatting
of comment blocks, even for those languages that do not need them. Vi
supports piping a region of text through an arbitrary program, so one
could easily have a filter that reformats such blocks.


These issues were all addressed in the Ada Language Rationale. I've found
Ada's comment syntax to be the best of any common language that I've used.


The moral is, I think, that language designers can and should assume a
reasonable editing environment. Just as you wouldn't send a carpenter out
to do a job without a hammer, you shouldn't send a programmer out to do a
job without a regular-expression-based editor.
--
    Lawrence Crowl 503-737-2554 Computer Science Department
crowl@cs.orst.edu Oregon State University
...!hplabs!hp-pcd!orstcs!crowl Corvallis, Oregon, 97331-3202
--

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