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. -- http://mail.python.org/mailman/listinfo/python-list
