comment style

[Martin Fouts]

>>>>> On 8 Jan 91 04:38:15 GMT, brnstnd at kramden.acf.nyu.edu (Dan Bernstein) said:

Dan> In article <616 at caslon.cs.arizona.edu> dave at cs.arizona.edu (Dave P. Schaumann) writes:
> In article <1050:Jan701:40:4791 at kramden.acf.nyu.edu> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:

   [ Discussion of point  deleted]

> |2. // is shorter and easier to type than /* */.
> |3. // is more visually striking than /* ... */.
> These are matters of personal taste.

Dan> No. #2 is an objective fact and #3 is a widely accepted principle of
Dan> visual design: parallel lines are striking. Read Tufte's books.

Sorry, #2 is not an objective fact.  In my editor of choice, I type
esc-; to "build" a comment.  It decides if I want // or /* */ from
various context clues and leaves me in the right place to enter the
comment.  I type newline when I'm through and the editor moves me on.
Same number of keystrokes in either case.

> |4. It is always obvious, to both human eye and mechanical parser, where
> |a // comment ends (viz., the end of the line). It is not so trivial to
> |locate the next */.
> My editor has a 'search for text' function.  Doesn't yours?

Dan> My eyes don't have a ``search for text'' function, and it takes just a
Dan> bit longer for the computer to recognize a two-character sequence than
Dan> to recognize a one-character sequence.

The latter is true, but irrelavent, as the "newline" character is
often a two character sequence internally in non Unix operating
systems.

> |5. Placing // at the beginning of several lines is guaranteed to comment
> |out the entire section. There is no easily applied rule for /*...*/.
> Comments are not for hiding code from the compiler.

Dan> But the fact is that people want to use comments to hide code (and
Dan> text). #if/#endif is not safe for hiding code and simply doesn't work
Dan> right for hiding text.

> However, as
> another post points out, // comments can have there own pitfalls when the line
> ends with a '\'.

Dan> No, not when they're done correctly. When you have end-of-line comments
Dan> there's no need for continuation characters. *All* characters are
Dan> ignored between // and newline inclusive.

Ah, but the other form isn't a problem "when done correctly" either.
The original a/*p problem goes away if you always follow the rule of
inserting whitespace between tokens.

Dan> ---Dan

Anyway, at this point, it would be nearly impossible to remove
'/*..*/' from the language, and the introduction of // adds additional
opportunities for ambiguity.  Consider the statement:

i = a//*p*/b;

This is a valid C statement now, but might not be if both kinds of
comments were supported in the language.

(Sigh.)

--
Martin Fouts
Software Craftsman

EMAIL:  fouts at apd.ingr.com
PHONE:  (415) 852-2310            FAX:  (415) 856-9224
 MAIL:  2400 Geng Road, Palo Alto, CA, 94303

Moving to Montana;  Goin' to be a Dental Floss Tycoon.
  -  Frank Zappa