A case for "real" multiline comments

[Chris Angelico]

On Thu, Apr 19, 2012 at 2:29 PM, Cameron Simpson <cs at zip.com.au> wrote:
> On 18Apr2012 22:07, Jordan Perr <jordan at jperr.com> wrote:
> | I came across this case while debugging some Python code that contained an
> | error stemming from the use of multiline strings as comments. The code
> | contained a very long list of objects, and I had commented out some of the
> | objects using the multiline string.
>
> You are aware that a string is not a comment?

They're often (ab)used as comments, since Python lacks a multiline
comment facility. Even docstrings are really comments in disguise.

> I'd just do this:
>
>  list = [
>  Object1(arg),
>  ## Object2(arg),
>  ## Object3(arg),
>  Object4(arg)
>  ]
>
> Multiple lines of single line comments. Frankly, I find this much easier
> to see (all the disabled lines are delineated with nice bright comment
> markers, and the beginning and end of the comment (were it a multiline
> comment) can't disappear off my screen.
>
> I would say you've made a case _against_ multiline coments.

On the contrary, he has definitely made a case for multiline comments.
You just happen to disagree, and you prefer single line comments. :)

I like multiline comments, but they do have their associated problems,
most notably nesting. It gets quite awkward commenting out code that
searches for comment markers, too.

Perhaps what's needed is not a C-style /* */ comment marker, but
something which must always be on a line of its own, and can therefore
ONLY delimit entire-line comments. Something like what's often done
with a preprocessor #if 0 #endif pair. There's no way you can "lose"
the #endif at the end of a line, and editors can still
syntax-highlight it (at least, SciTE does; haven't looked at many
editors lately). It nests correctly, but can't ever mis-nest with a
literal string. Thoughts?

ChrisA