473,288 Members | 1,710 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,288 software developers and data experts.

multiline comments

At the risk of flogging a dead horse, I'm wondering why Python doesn't have
any multiline comments. One can abuse triple-quotes for that purpose, but
that's obviously not what it's for and doesn't nest properly. ML has a
very elegant system for nested comments with (* and *).

Using an editor to throw #s in front of every line has limitations. Your
editor has to support it and you have to know how to use that feature. Not
exactly intuitive or easy for novices to pick up. Also a pain if your
preferred editor is python/perl/sh-agnostic.

Saying coders shouldn't use multiline comments to disable code misses the
point. Coders will comment out code regardless of the existence of
multiline comemnts. There has to be a better argument for leaving them out.

Keeping the language small and simple is desirable, but it's not an
absolute. A little syntactic sugar like 'for x in s' makes code easier to
read than 'for i in len(s): x = s[i]'. So what are the tradeoffs involved
with nested multiline comments? I'd like to understand the reasoning
behind keeping them out.
Apr 19 '06 #1
40 4544
Edward Elliott wrote:
At the risk of flogging a dead horse, I'm wondering why Python doesn't
have any multiline comments. One can abuse triple-quotes for that
purpose, but that's obviously not what it's for and doesn't nest
properly. ML has a very elegant system for nested comments with (* and *).

Using an editor to throw #s in front of every line has limitations.
Your editor has to support it and you have to know how to use that
feature. Not exactly intuitive or easy for novices to pick up. Also a
pain if your preferred editor is python/perl/sh-agnostic.

Saying coders shouldn't use multiline comments to disable code misses
the point. Coders will comment out code regardless of the existence of
multiline comemnts. There has to be a better argument for leaving them
out.

Keeping the language small and simple is desirable, but it's not an
absolute. A little syntactic sugar like 'for x in s' makes code easier
to read than 'for i in len(s): x = s[i]'. So what are the tradeoffs
involved with nested multiline comments? I'd like to understand the
reasoning behind keeping them out.


I think the absence of multiline comments is like the requirement for
indentation. It enforces good habits. Better is to make your multiple
lines a function and comment out the function call.

James

--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095

http://www.jamesstroud.com/
Apr 19 '06 #2
James Stroud <js*****@ucla.edu> writes:
Edward Elliott wrote:
At the risk of flogging a dead horse, I'm wondering why Python
doesn't have any multiline comments. [...]

Using an editor to throw #s in front of every line has
limitations. Your editor has to support it and you have to know
how to use that feature. Not exactly intuitive or easy for
novices to pick up. Also a pain if your preferred editor is
python/perl/sh-agnostic.


I think the absence of multiline comments is like the requirement
for indentation. It enforces good habits. Better is to make your
multiple lines a function and comment out the function call.


And/or switch to an editor that can perform editing operations on a
range of lines.

--
\ Q: "I've heard that Linux causes cancer..." Torvalds: "That's |
`\ a filthy lie. Besides, it was only in rats and has not been |
_o__) reproduced in humans." -- Linus Torvalds |
Ben Finney

Apr 19 '06 #3

Edward Elliott wrote:
At the risk of flogging a dead horse, I'm wondering why Python doesn't have
any multiline comments. One can abuse triple-quotes for that purpose, but
that's obviously not what it's for and doesn't nest properly. .... Saying coders shouldn't use multiline comments to disable code misses the
point. Coders will comment out code regardless of the existence of
multiline comemnts. There has to be a better argument for leaving them out.


i beg to differ: you'd be surprised how much effect can little
inconveniences have.

want to comment block of code? use tripple-quotes. does not nest? ahhh,
maybe it's time to get rid of that block you commented out a month ago
"just in case the new code doesnt work".

that gives you incentive to tidy up. don't be a code slob... don't
leave a mess forever ;-)

Apr 19 '06 #4
"Atanas Banov" <en****@gmail.com> writes:
Edward Elliott wrote:
Saying coders shouldn't use multiline comments to disable code
misses the point. Coders will comment out code regardless of the
existence of multiline comemnts. There has to be a better
argument for leaving them out.


i beg to differ: you'd be surprised how much effect can little
inconveniences have.

want to comment block of code? use tripple-quotes. does not nest?
ahhh, maybe it's time to get rid of that block you commented out a
month ago "just in case the new code doesnt work".


Indeed. Using revision control means never needing to comment out
blocks of code.

If your revision control system is so inconvenient to use that you'd
rather have large blocks of commented-out code, it's time to start
using a better RCS -- perhaps a distributed one, so you can commit to
your own local repository with abandon while trying out changes.

--
\ "I saw a sign: 'Rest Area 25 Miles'. That's pretty big. Some |
`\ people must be really tired." -- Steven Wright |
_o__) |
Ben Finney

Apr 19 '06 #5
Atanas Banov wrote:
want to comment block of code? use tripple-quotes. does not nest? ahhh,
maybe it's time to get rid of that block you commented out a month ago
"just in case the new code doesnt work".

that gives you incentive to tidy up. don't be a code slob... don't
leave a mess forever ;-)


And when the section I want to comment out contains a legit doc string in
the middle, triple-quotes won't work. There are valid reasons to nest
comments which have nothing to do with laziness or sloppy code.

Forcing programmers to write clean code with syntax is like teaching a pig
to sing: it wastes your time and annoys the pig. Good coding is a state of
mind, not a parser option.
Apr 19 '06 #6
Ben Finney wrote:
And/or switch to an editor that can perform editing operations on a
range of lines.


I'm not unsympathetic to this point of view, as I would feel hamstrung
without my vim. It's more that I object to the paternalism of telling
people they have to use such an editor. There are times when notepad is
all that's available.

On top of that, the expressive power of nested comments seems greater than
an endless string of ^#s. Sometimes it's just easier to see what's going on.
Apr 19 '06 #7
Ben Finney wrote:
Indeed. Using revision control means never needing to comment out
blocks of code.


Typing (* and *) on a few line will always be quicker, easier, and less
confusing than any rcs diffs/restores. Once you delete the code you can no
longer see it or add pieces back in without retrieving it from an external
store. I'm not saying nested comments solve every problem, just that there
exists a certain (perhaps small) class of problems they solve particularly
well.

Personally, I rarely leave code commented out beyond a single coding
session. But my particular coding habits aren't relevant here.
Apr 19 '06 #8
In article <wZ*******************@newssvr21.news.prodigy.com> ,
Edward Elliott <no****@127.0.0.1> wrote:
ML has a
very elegant system for nested comments with (* and *).


Which, if you mistype an opening or closing comment symbol, can lead to
some very mysterious syntax errors.
Apr 19 '06 #9
Edward Elliott wrote:
Ben Finney wrote:
Indeed. Using revision control means never needing to comment out
blocks of code.
Typing (* and *) on a few line will always be quicker, easier, and
less confusing than any rcs diffs/restores. Once you delete the code
you can no longer see it or add pieces back in without retrieving it
from an external store. I'm not saying nested comments solve every
problem, just that there exists a certain (perhaps small) class of
problems they solve particularly well.


Would you care to name a few languages which support nested block
comments? There really aren't many: ML as you mentioned; Standard Pascal
doesn't permit nesting of comments but *some* implementations do allow it.

Want to comment out a block of code in C++? The only (nearly) reliable way
is to insert single-line comments down the block. You can't use a block
comment if there are any other block comments inside the code you want to
block out.

The danger of block comments is that if you forget to close the comment
you can accidentally comment out a large part of your code. With support
from the editor (coloured highlighting of comments) this isn't so bad,
but then if you have a decent editor you don't need the block comments
anyway as you will be able to comment/uncomment a block in your editor.

Doc strings will usually work as an alternative, especially since you
have a choice of two flavours of triple quoted strings, so if you use
one for docstrings the other is always free for your temporary block
comments.
Forcing programmers to write clean code with syntax is like teaching a
pig to sing: it wastes your time and annoys the pig.


This pig gets much more annoyed having to maintain code which has large
chunks of unneeded commented out code left over from some other programmer,
or which has completely messed up indentation.
Apr 19 '06 #10
Duncan Booth schreef:
Would you care to name a few languages which support nested block
comments? There really aren't many: ML as you mentioned; Standard Pascal
doesn't permit nesting of comments but *some* implementations do allow it.

Want to comment out a block of code in C++? The only (nearly) reliable way
is to insert single-line comments down the block. You can't use a block
comment if there are any other block comments inside the code you want to
block out.


Depends, some compilers support that. But the preferred way, which works
very well, is to use preprocessor directives:

#if 0
...
#endif

Works in both C and C++.

--
If I have been able to see further, it was only because I stood
on the shoulders of giants. -- Isaac Newton

Roel Schroeven
Apr 19 '06 #11
Duncan Booth wrote:
Want to comment out a block of code in C++? The only (nearly) reliable way
is to insert single-line comments down the block. You can't use a block
comment if there are any other block comments inside the code you want to
block out.
As Roel said, #if 0 is the standard way. It abuses the preprocessor and
doesn't show up in syntax highlighting, but other than that works very
well. Honestly though, /* and */ should have nested properly since day 1.
Adding it wouldn't even break existing code.
The danger of block comments is that if you forget to close the comment
you can accidentally comment out a large part of your code.
No, unclosed comments should raise a syntax error. Would you accept an
unclosed string literal?
Doc strings will usually work as an alternative, especially since you
have a choice of two flavours of triple quoted strings, so if you use
one for docstrings the other is always free for your temporary block
comments.
That's a fair point, if a bit of a kludge. 90% there is good enough in
practice.
This pig gets much more annoyed having to maintain code which has large
chunks of unneeded commented out code left over from some other programmer,
or which has completely messed up indentation.


Sure they can be abused. So can a thousand other language features. My
point is you can't teach good coding through syntax, and trying to causes
more problems than it solves.

I would argue the current system is in fact slightly worse, because people
will comment out code chunks anyway (either lots of #s or triple-quotes)
and are less likely to remove them when it's more work. But either way,
social pressure is infinitely more effective at cleaning up code than
comment syntax.
Apr 19 '06 #12
Edward Elliott schrieb:
On top of that, the expressive power of nested comments seems greater
than an endless string of ^#s. Sometimes it's just easier to see what's
going on.


not if you are using grep

--
Gregor
http://www.gregor-horvath.com
Apr 19 '06 #13
Ben Finney wrote:
"Atanas Banov" <en****@gmail.com> writes:
Edward Elliott wrote:
Saying coders shouldn't use multiline comments to disable code
misses the point. Coders will comment out code regardless of the
existence of multiline comemnts. There has to be a better
argument for leaving them out.

i beg to differ: you'd be surprised how much effect can little
inconveniences have.

want to comment block of code? use tripple-quotes. does not nest?
ahhh, maybe it's time to get rid of that block you commented out a
month ago "just in case the new code doesnt work".


Indeed. Using revision control means never needing to comment out
blocks of code.

If your revision control system is so inconvenient to use that you'd
rather have large blocks of commented-out code, it's time to start
using a better RCS -- perhaps a distributed one, so you can commit to
your own local repository with abandon while trying out changes.


I'm not sure I agree, revision control is great but not the only answer.
In multi-developer teams working on the trunk, it its kind of
inconvenient if someone checks in broken code. It also blocks critical
path development if the person responsible for the code you conflict
with happens to be out on holiday. Block commenting is a clear flag to
that developer that something has changed - ideally he'd notice, see
sensible revision control comments, see the flag on the wiki or you
would remember to tell him. But if all of that fails, if it is commented
in the code it should get picked up at a code review.

Personally, I prefer clear code, minimally commented with good high
level descriptions of particularly complex section / algorithms. The
later doesn't always fit neatly on one line. There is an argument that
these should go into their own functions and be commented at the
function level. Again I'm not sure I agree entirely - function comments
that are auto extracted to create api docs (sorry Java background :-))
need only outline What a function does. There is a place for multiline
comments to describe How that is achieved.

Having said all that, I generally don't like comments, they are often
maintained poorly, too numerous, too verbose (red rag :-)) - so i'm
undecided whether they should be made easier for developers or
discouraged except where vital. Perhaps we should make them really hard
and elegant - mandate latex/mathml markup so good editors can display
the equations we are implementing :-)
Apr 19 '06 #14
Edward Elliott wrote:
Typing (* and *) on a few line will always be quicker, easier, and less
confusing than any rcs diffs/restores. Once you delete the code you can
no longer see it or add pieces back in without retrieving it from an
external store.
Try using Subversion. You can work and make diffs disconnected from the
network. You can't, of course, commit / update but you can work with it
and have what you need to compare original code (i.e. the one from the last
commit) to new code and go back to original code if needed.
I'm not saying nested comments solve every problem, just that
there exists a certain (perhaps small) class of problems they solve
particularly well.
I don't miss them. :-)
Personally, I rarely leave code commented out beyond a single coding
session. But my particular coding habits aren't relevant here.


Well, I believe they are since it looks like a habit of yours to use
multiline comments. It is common for people coming from other programming
languages that support them.

--
Jorge Godoy <go***@ieee.org>

"Quidquid latine dictum sit, altum sonatur."
- Qualquer coisa dita em latim soa profundo.
- Anything said in Latin sounds smart.
Apr 19 '06 #15
Edward Elliott wrote:
Sure they can be abused. So can a thousand other language features. My
point is you can't teach good coding through syntax, and trying to causes
more problems than it solves.
I like the phrase: there are some languages that incentivates bad practices
in programming; there is Python that doesn't.

Some rigid syntax indeed makes you think one way -- and that's one of
Python's motto, isn't it? "There's one right way to do it" -- but that
will make your code more understandable and readable in the future.
I would argue the current system is in fact slightly worse, because people
will comment out code chunks anyway (either lots of #s or triple-quotes)
and are less likely to remove them when it's more work. But either way,
social pressure is infinitely more effective at cleaning up code than
comment syntax.


Is it harder to remove "n" lines of code commented out with "#" than "n"
lines of multiline commented code? How? The same question goes for triple
quoted code.

--
Jorge Godoy <go***@ieee.org>

"Quidquid latine dictum sit, altum sonatur."
- Qualquer coisa dita em latim soa profundo.
- Anything said in Latin sounds smart.
Apr 19 '06 #16
Peter Tillotson wrote:
I'm not sure I agree, revision control is great but not the only answer.
In multi-developer teams working on the trunk, it its kind of
inconvenient if someone checks in broken code. It also blocks critical
This is something that should be a policy: no untested and working code
should be commited to the trunk; if you need to commit it for any reason
create a branch and do it there.
path development if the person responsible for the code you conflict
with happens to be out on holiday. Block commenting is a clear flag to
Here I believe that no code revision system is a substitute for project. If
you have two conflicting changes on the same line of code, then you surely
are missing some discussion on the code and more documentation on what is
being done / has been done. Revision management is no substitute for
meetings and projects.
that developer that something has changed - ideally he'd notice, see
sensible revision control comments, see the flag on the wiki or you
would remember to tell him. But if all of that fails, if it is commented
in the code it should get picked up at a code review.
I believe that it is easier to see multiple commented out lines than just
the beginning and ending of a multiline comment. Specially when you're
screening the code instead of reading it line by line.
Personally, I prefer clear code, minimally commented with good high
level descriptions of particularly complex section / algorithms. The
We have the same taste, except that I prefer documenting more things than
just complex algorithms so I have a lot of comments and docstrings in my
code.
later doesn't always fit neatly on one line. There is an argument that
these should go into their own functions and be commented at the
function level. Again I'm not sure I agree entirely - function comments
that are auto extracted to create api docs (sorry Java background :-))
need only outline What a function does. There is a place for multiline
comments to describe How that is achieved.
I still believe that you're working with an inappropriate environment if
your editor can't use some extension for the language you choose (coming
from a Java background you might like PyDev on Eclipse, even though its
indentation features aren't as nice as Emacs' features...) or being able to
repeat the comment symbol from one line to the next when it wraps (keeping
indentation, of course!)
Having said all that, I generally don't like comments, they are often
maintained poorly, too numerous, too verbose (red rag :-)) - so i'm
undecided whether they should be made easier for developers or
discouraged except where vital. Perhaps we should make them really hard
and elegant - mandate latex/mathml markup so good editors can display
the equations we are implementing :-)


:-) There's an approach that allows using those... I don't remember which
docsystem allows for MathML markup. But then, I'd go with DocBook + MathML
+ SVG ;-) (Hey! You started! And you even said that you didn't like
verbose comments... ;-))

--
Jorge Godoy <go***@ieee.org>

"Quidquid latine dictum sit, altum sonatur."
- Qualquer coisa dita em latim soa profundo.
- Anything said in Latin sounds smart.
Apr 19 '06 #17
Edward Elliott wrote:
And when the section I want to comment out contains a legit doc string in
the middle, triple-quotes won't work. There are valid reasons to nest
You can use either """ or '''. I don't keep changing them in my code, so I
can always use the other type (usually I use " so for commenting things out
I'd use ') to do that.
comments which have nothing to do with laziness or sloppy code.

Forcing programmers to write clean code with syntax is like teaching a pig
to sing: it wastes your time and annoys the pig. Good coding is a state
of mind, not a parser option.


If the latter can help, why not?

--
Jorge Godoy <go***@ieee.org>

"Quidquid latine dictum sit, altum sonatur."
- Qualquer coisa dita em latim soa profundo.
- Anything said in Latin sounds smart.
Apr 19 '06 #18
nice one Jorge :-)

Jorge Godoy wrote:
Peter Tillotson wrote:
I'm not sure I agree, revision control is great but not the only answer.
In multi-developer teams working on the trunk, it its kind of
inconvenient if someone checks in broken code. It also blocks critical


This is something that should be a policy: no untested and working code
should be commited to the trunk; if you need to commit it for any reason
create a branch and do it there.

typo

committing broken code to trunk should punishable by stocks at least --
perhaps a public flogging.

Though on a serious note, you need a good reason for creating arbitrary
branches and a clearly defined naming policy. You also need to remember
to get off the branch asap before you inadvertently start a major fork.
path development if the person responsible for the code you conflict
with happens to be out on holiday. Block commenting is a clear flag to


Here I believe that no code revision system is a substitute for project. If
you have two conflicting changes on the same line of code, then you surely
are missing some discussion on the code and more documentation on what is
being done / has been done. Revision management is no substitute for
meetings and projects.
that developer that something has changed - ideally he'd notice, see
sensible revision control comments, see the flag on the wiki or you
would remember to tell him. But if all of that fails, if it is commented
in the code it should get picked up at a code review.


I believe that it is easier to see multiple commented out lines than just
the beginning and ending of a multiline comment. Specially when you're
screening the code instead of reading it line by line.
Personally, I prefer clear code, minimally commented with good high
level descriptions of particularly complex section / algorithms. The


We have the same taste, except that I prefer documenting more things than
just complex algorithms so I have a lot of comments and docstrings in my
code.
later doesn't always fit neatly on one line. There is an argument that
these should go into their own functions and be commented at the
function level. Again I'm not sure I agree entirely - function comments
that are auto extracted to create api docs (sorry Java background :-))
need only outline What a function does. There is a place for multiline
comments to describe How that is achieved.


I still believe that you're working with an inappropriate environment if
your editor can't use some extension for the language you choose (coming
from a Java background you might like PyDev on Eclipse, even though its
indentation features aren't as nice as Emacs' features...) or being able to
repeat the comment symbol from one line to the next when it wraps (keeping
indentation, of course!)

Sadly i don't get to code at the coalface much recently. I've tinkered
in python with pydev and vi over the last couple of years - i just
really dislike coding on a white background. I'm sure eclipse can do it
- i'm just not sure i've got the perseverance to work out how.
Having said all that, I generally don't like comments, they are often
maintained poorly, too numerous, too verbose (red rag :-)) - so i'm
undecided whether they should be made easier for developers or
discouraged except where vital. Perhaps we should make them really hard
and elegant - mandate latex/mathml markup so good editors can display
the equations we are implementing :-)


:-) There's an approach that allows using those... I don't remember which
docsystem allows for MathML markup. But then, I'd go with DocBook + MathML
+ SVG ;-) (Hey! You started! And you even said that you didn't like
verbose comments... ;-))

oooh - but surely a picture is worth a thousand words and with SVG no
truer word was spoken :-)

I was only half kidding about latex. I can just about read pure latex
but that human readable xml stuff always defeats me
Apr 19 '06 #19
Edward Elliott <no****@127.0.0.1> wrote:
On top of that, the expressive power of nested comments seems greater than
an endless string of ^#s. Sometimes it's just easier to see what's going on.


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

--
\S -- si***@chiark.greenend.org.uk -- http://www.chaos.org.uk/~sion/
___ | "Frankly I have no feelings towards penguins one way or the other"
\X/ | -- Arthur C. Clarke
her nu becomež se bera eadward ofdun hlęddre heafdes bęce bump bump bump
Apr 19 '06 #20
Jorge Godoy <go***@ieee.org> wrote:
Is it harder to remove "n" lines of code commented out with "#" than "n"
lines of multiline commented code? How?


I'd say it's harder to remove the latter, due to having to search for
the end of comment sequence, rather than simply looking for where the
block comment stops. And you've extra problems if you allow nested
comments, because then you'll have to count how deep you've gone. Of
course, if you can completely trust your editor's syntax highlighter
you might be OK, but wasn't part of the point of this argument about
not *requiring* smart editors to be productive?

--
\S -- si***@chiark.greenend.org.uk -- http://www.chaos.org.uk/~sion/
___ | "Frankly I have no feelings towards penguins one way or the other"
\X/ | -- Arthur C. Clarke
her nu becomež se bera eadward ofdun hlęddre heafdes bęce bump bump bump
Apr 19 '06 #21
Sion Arrowsmith wrote:
I'd say it's harder to remove the latter, due to having to search for
the end of comment sequence, rather than simply looking for where the
block comment stops. And you've extra problems if you allow nested
comments, because then you'll have to count how deep you've gone. Of
course, if you can completely trust your editor's syntax highlighter
you might be OK, but wasn't part of the point of this argument about
not *requiring* smart editors to be productive?


Also, if you remove the start of the block first, then your editor might not
be highlighting anymore... With nested comments things get even worse
because you might miss the end of the outer block or something like that.

--
Jorge Godoy <go***@ieee.org>

"Quidquid latine dictum sit, altum sonatur."
- Qualquer coisa dita em latim soa profundo.
- Anything said in Latin sounds smart.
Apr 19 '06 #22
rx

"Edward Elliott" <no****@127.0.0.1> wrote in message
news:UR*******************@newssvr21.news.prodigy. com...
Ben Finney wrote:
Indeed. Using revision control means never needing to comment out
blocks of code.


Typing (* and *) on a few line will always be quicker, easier, and less
confusing than any rcs diffs/restores. Once you delete the code you can
no longer see it or add pieces back in without retrieving it from an
external store. I'm not saying nested comments solve every problem, just
that there exists a certain (perhaps small) class of problems they solve
particularly well.

Personally, I rarely leave code commented out beyond a single coding
session. But my particular coding habits aren't relevant here.

Well I perfectly agree, and why make a dependence on external tools
(IDE/CVS) if you can build it into the language with no conflicts by using
some strange ascii combinations. I'm sure something like:

a()
(#
b()
c()
#)
d()

would be fine.
Apr 19 '06 #23
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.
Apr 19 '06 #24
rx

"Jorge Godoy" <go***@ieee.org> wrote in message
news:21****************@jupiter.g2ctech...
Edward Elliott wrote:

You can use either """ or '''. I don't keep changing them in my code, so
I
can always use the other type (usually I use " so for commenting things
out
I'd use ') to do that.


Try that on this code:

a=3
a=a*a
b='''This is a
very long
long
text'''
print a
like:

a=3
'''
a=a*a
b='''This is a
very long
long
text'''
'''
print a

raises SyntaxError
Apr 19 '06 #25
Sion Arrowsmith wrote:
Jorge Godoy <go***@ieee.org> wrote:
Is it harder to remove "n" lines of code commented out with "#" than "n"
lines of multiline commented code? How?


I'd say it's harder to remove the latter, due to having to search for
the end of comment sequence, rather than simply looking for where the
block comment stops.


Like I said, it's debatable. Depends on the editing conditions you assume.
It's easy to imagine situations where either type comes out ahead.
Apr 19 '06 #26
Jorge Godoy wrote:
Edward Elliott wrote:
Try using Subversion. You can work and make diffs disconnected from the
network.
rcs isn't the issue. I'm already assuming a local store, a networked one
just makes my argument even easier.
I'm not saying nested comments solve every problem, just that


I don't miss them. :-)


Fair enough.
Well, I believe they are since it looks like a habit of yours to use
multiline comments. It is common for people coming from other programming
languages that support them.


Yes I cut my teeth on C, C++, and Java. That was a long time ago. I don't
miss them because they're more C-like (the C-family actually has an awful
implementation), I miss them because they're useful. Actually I never used
multiline much until I did a project in ML and saw how they should work.

However the last 4 years I've used Perl, Python, and PHP almost
exclusively. I'm used to single-line comments, I just find their
expressive power lacking. No shame in borrowing the best features of other
languages.
Apr 19 '06 #27
rx

Also, if you remove the start of the block first, then your editor might
not
be highlighting anymore... With nested comments things get even worse
because you might miss the end of the outer block or something like that.

--
Jorge Godoy <go***@ieee.org>


I have commented out a lot of C++ code and miss the block feature in python
more than I missed the nested comments in C++.
Besides nothing really strange happened.
Sometimes you just need to dissable some of the code temporarly as quickly
as possible, and I like that it is not higlighted any more, since I will not
look into it before I dissable the comment.
Apr 19 '06 #28
Peter Tillotson wrote:
discouraged except where vital. Perhaps we should make them really hard
and elegant - mandate latex/mathml markup so good editors can display
the equations we are implementing :-)


I like this guy already! :)
Apr 19 '06 #29
Jorge Godoy wrote:
You can use either """ or '''. I don't keep changing them in my code, so I
can always use the other type (usually I use " so for commenting things out
I'd use ') to do that.


It's close, only problem is it doesn't nest. It'll have to be good enough
for now.
Forcing programmers to write clean code with syntax is like teaching a pig
to sing: it wastes your time and annoys the pig. Good coding is a state
of mind, not a parser option.


If the latter can help, why not?


Because in this case it limits the expressive power of the language.
Multiline comments enable clearer communication of intent (see earlier post
for some reasons why).
Apr 19 '06 #30
rx wrote:
I have commented out a lot of C++ code and miss the block feature in
python more than I missed the nested comments in C++.
Besides nothing really strange happened.
Sometimes you just need to dissable some of the code temporarly as quickly
as possible, and I like that it is not higlighted any more, since I will
not look into it before I dissable the comment.


This is how I do it: select the lines I want to comment and ask Emacs to
comment that region. It is the same command and method for "n" different
languages and I don't care if there is multiline comment support or not.
It is really as fast as inserting /* and ending with */ (in fact, I type
less than to achieve that since I only use three keys, counting the
Ctrl-Space to start the block).

--
Jorge Godoy <go***@ieee.org>

"Quidquid latine dictum sit, altum sonatur."
- Qualquer coisa dita em latim soa profundo.
- Anything said in Latin sounds smart.
Apr 19 '06 #31
rx wrote:

"Jorge Godoy" <go***@ieee.org> wrote in message
news:21****************@jupiter.g2ctech...
Edward Elliott wrote:


You can use either """ or '''. I don't keep changing them in my code, so
I
can always use the other type (usually I use " so for commenting things
out
I'd use ') to do that.


Try that on this code:

a=3
a=a*a
b='''This is a
very long
long
text'''
print a
like:

a=3
'''
a=a*a
b='''This is a
very long
long
text'''
'''
print a

raises SyntaxError


Of course! You should have used """ since you already used ''' in your
triple-quoted text. But I'm just repeating what I already said (and kept
above so that you can see it again).

--
Jorge Godoy <go***@ieee.org>

"Quidquid latine dictum sit, altum sonatur."
- Qualquer coisa dita em latim soa profundo.
- Anything said in Latin sounds smart.
Apr 19 '06 #32
rx

"Jorge Godoy" <go***@ieee.org> wrote in message
news:12****************@jupiter.g2ctech...
rx wrote:
I have commented out a lot of C++ code and miss the block feature in
python more than I missed the nested comments in C++.
Besides nothing really strange happened.
Sometimes you just need to dissable some of the code temporarly as
quickly
as possible, and I like that it is not higlighted any more, since I will
not look into it before I dissable the comment.


This is how I do it: select the lines I want to comment and ask Emacs to
comment that region. It is the same command and method for "n" different
languages and I don't care if there is multiline comment support or not.
It is really as fast as inserting /* and ending with */ (in fact, I type
less than to achieve that since I only use three keys, counting the
Ctrl-Space to start the block).


It would be much nicer to have it in the language since there are many
editors and many ways to do what you do (it would also make it more easy to
make a editor).
Besides it could be done with two keys if that really important - but I
doubt it.
But in a way you are also right if you use more than a few languages in the
same editor, but then again the editor would still be able to do the
commenting if you prefered that.
I don't understand the problem - why should comments (and I hope you believe
there should be a one line comment at least) be restricted to one line.
It doesn't work that way for if, while, for.
Apr 19 '06 #33
rx wrote:
I don't understand the problem - why should comments (and I hope you
believe there should be a one line comment at least) be restricted to one
line. It doesn't work that way for if, while, for.


It is the minimum case that can solve a problem commenting one line -- or
part of it as in "print '3' # print the number 3" -- or commenting multiple
lines. It is also easier to deal with since you don't have to end your
comment all the time.

For "if", "while", "for", etc. you have ":" and the indentation. You don't
have an "endif", "endwhile", "endfor" (so, why having an "end comment"?).

--
Jorge Godoy <go***@ieee.org>

"Quidquid latine dictum sit, altum sonatur."
- Qualquer coisa dita em latim soa profundo.
- Anything said in Latin sounds smart.
Apr 19 '06 #34
rx

Of course! You should have used """ since you already used ''' in your
triple-quoted text. But I'm just repeating what I already said (and kept
above so that you can see it again).

--
Jorge Godoy <go***@ieee.org>


Sorry - I should have read more carefully.
I like the idea and will use it I think.
Still a little strange to newcomers that there are three ways to do the same
and that you should be carefull to use the right '''/""" inside the comment
else the comment will not work for some reason.

#comment

'''
comment
'''

"""
comment
"""
Apr 19 '06 #35
rx

"Jorge Godoy" <go***@ieee.org> wrote in message
news:17****************@jupiter.g2ctech...
rx wrote:
I don't understand the problem - why should comments (and I hope you
believe there should be a one line comment at least) be restricted to one
line. It doesn't work that way for if, while, for.


It is the minimum case that can solve a problem commenting one line -- or
part of it as in "print '3' # print the number 3" -- or commenting
multiple
lines. It is also easier to deal with since you don't have to end your
comment all the time.

For "if", "while", "for", etc. you have ":" and the indentation. You
don't
have an "endif", "endwhile", "endfor" (so, why having an "end comment"?).

--
Jorge Godoy <go***@ieee.org>


There no reason why a multiple line comment couldn't be indented (then the
indentation is the end of comment in some sense), but I don't find that
logical - after all its my comment and I don't want python to tell me how to
indent it.
Apr 19 '06 #36
rx wrote:
Still a little strange to newcomers that there are three ways to do the
same and that you should be carefull to use the right '''/""" inside the
comment else the comment will not work for some reason.

#comment

'''
comment
'''

"""
comment
"""


Please, note that triple quotes are not for comments. They may be used like
that and they are used like that, but their primary intention is for
multiline strings (something like the here docs in Perl, for example).

Triple quotes can also be used like this:

usage = """
This program accepts the following options:

--help, -h Display this message
--verbose, -v Display more details
"""

This defines a multiline string. If you had to use only single quotes then
you'd have to insert "\n" for each newline.

--
Jorge Godoy <go***@ieee.org>

"Quidquid latine dictum sit, altum sonatur."
- Qualquer coisa dita em latim soa profundo.
- Anything said in Latin sounds smart.
Apr 19 '06 #37
Ben Finney wrote:
Indeed. Using revision control means never needing to comment out
blocks of code.

If your revision control system is so inconvenient to use that you'd
rather have large blocks of commented-out code, it's time to start
using a better RCS -- perhaps a distributed one, so you can commit to
your own local repository with abandon while trying out changes.


I don't buy this kind of argument. It seems strange to say that
the language is designed a certain way because users are expected to use
certain kinds of third-party tools to manage their code. What if I'm
just putting together a little script to do something and I don't want
to mess with a revision control system?

--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown
Apr 20 '06 #38
"OKB (not okblacke)" <br************@NObrenSPAMbarn.net> writes:
Ben Finney wrote:
If your revision control system is so inconvenient to use that
you'd rather have large blocks of commented-out code, it's time to
start using a better RCS -- perhaps a distributed one, so you can
commit to your own local repository with abandon while trying out
changes.
I don't buy this kind of argument. It seems strange to say
that the language is designed a certain way because users are
expected to use certain kinds of third-party tools to manage their
code.


You're reading a causal relationship where none was asserted.
What if I'm just putting together a little script to do something
and I don't want to mess with a revision control system?


If it's so little, why are single-line comments not enough?

If it's large enough that large blocks of code need changing
frequently, I assert revision control is needed.

The barriers to using a good revision control system are so low these
days it's poor practice to avoid using one for anything but throw-away
programs.

--
\ "The illiterate of the future will not be the person who cannot |
`\ read. It will be the person who does not know how to learn." |
_o__) -- Alvin Toffler |
Ben Finney

Apr 20 '06 #39
Edward Elliott <no****@127.0.0.1> wrote:
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:
[ ... ]


It appears to me that our fundamental difference is that you see value
in long-term preservation of sections of commented-out code without
any kind of real comment as to what's going on, whereas I consider
this to be appallingly bad practice.

--
\S -- si***@chiark.greenend.org.uk -- http://www.chaos.org.uk/~sion/
___ | "Frankly I have no feelings towards penguins one way or the other"
\X/ | -- Arthur C. Clarke
her nu becomež se bera eadward ofdun hlęddre heafdes bęce bump bump bump
Apr 20 '06 #40
Sion Arrowsmith wrote:
It appears to me that our fundamental difference is that you see value
in long-term preservation of sections of commented-out code without
any kind of real comment as to what's going on, whereas I consider
this to be appallingly bad practice.


Then you're reading too much into my examples. Real code would be
accompanied by descriptive comments.
Apr 20 '06 #41

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

4
by: FLEB | last post by:
I like PHP for its excellent inline integration into standard HTML files, but I like Perl for its quick-moving syntax and simpler data-processing. To resolve this deep-seated inner turmoil (oh, the...
32
by: Elliot Temple | last post by:
Hi I have two questions. Could someone explain to me why Python is case sensitive? I find that annoying. Also, why aren't there multiline comments? Would adding them cause a problem of some...
4
by: Uwe Ziegenhagen | last post by:
Hello, my fellows and me implement a c++ tool that is able to divide blank/tab separated files into <number>, <text>, <c-singlelinecomment> and <multilinecomment>. So far it's not working bad,...
2
by: pothik05 | last post by:
I have a multiline textbox (with scrollbar) on a form. I add lines to the textbox at runtime. If the number of lines crosses the visible area in the textbox, I want the scrollbar to scrolldown. I...
1
by: Laser Lu | last post by:
Hi, all, I'm now writing a program to compress JavaScript code. One puzzle is how to write a regular expression to find out and remove all the redundent blank spaces. However, those blank spaces...
2
by: JohnMSyrasoft | last post by:
Hi, wondering if I'm missing something before I log a minor bug to the VS2005 feedback page. In VB6, you could span multiple lines with comments by using a line continuation character as in ...
0
by: Dan Sikorsky | last post by:
I have labels and associated multiline textboxes on a panel that's disabled for the purpose of presenting lengthy readonly comments. Using this method, the textbox scrollbars don't work; the user...
4
by: anilga | last post by:
Hi , I am a starter with perl on windows. I need to match commented lines like below /* comments * comments comments */ Whats the exact reg exp in windows perl script to use for this.
29
by: s0suk3 | last post by:
I was shocked a while ago when a discovered that in Python you can't do a multiline assignment with comments between the lines. For example, let's say I want to assign a bunch of variables to an...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM). In this month's session, the creator of the excellent VBE...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: Aftab Ahmad | last post by:
Hello Experts! I have written a code in MS Access for a cmd called "WhatsApp Message" to open WhatsApp using that very code but the problem is that it gives a popup message everytime I clicked on...
0
by: Aftab Ahmad | last post by:
So, I have written a code for a cmd called "Send WhatsApp Message" to open and send WhatsApp messaage. The code is given below. Dim IE As Object Set IE =...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.