multiline comments

[Edward Elliott]

Sion Arrowsmith wrote:
> Really? Under what circumstances is it easier to see what's going on
> with start/end comments than with comment-to-end-of-line?

Off the top of my head:
1. The code is usually easier to read as # can obscure the first token on 
the line.  This can be alleviated by leaving a space after the # or 
coloring the # differently.

2. It's easier to see where a nested comment begins and ends.  Instead of 
counting #s at the beginning of lines, just find the matching closer.  This 
is fairly simple to automate in a good editor.  Counting #s can be 
automated as well, but fails if the programmer gets lazy and doesn't add 
extra #s when nesting, i.e. turns this:

line 1
#line 2
line 3

into this

#line 1
#line 2
#line 3

instead of this

#line 1
##line 2
#line 3

3. Preserves history better.  Say I have consecutive lines commented out. 
With #s, all you see is this:

#line 1
#line 2
#line 3
#line 4

If they were commented out in two chunks at different times, multiline 
comments can preserve that information:

(*
line 1
line 2
*)
(*
line 3
line 4
*)

This isn't meant to be an exhaustive list.  There are ways to address all 
these things with single-line comments, but it takes more work.  Economy of 
expression favors nested comments in my book.

Gregor has a good point about grep, but C-based languages with /**/ suffer 
the same problem.  I think the answer is smarter searches, not dumber comments.