"Martin York" <Martin.York@veritas.com> wrote in message news:a27fv5$quv$1@digitaldaemon.com...

> Maybe this is a feature that needs to be added to languages (in general) The ability to "comment" out sections of code for debugging purposes, but that refuses to compile in release mode.

D has this, in form of debug() statement (RTFM!). Comments, however,
can be used for lots other purposes.

BTW an alternative to nested comments could be another, alternative, syntax - like in Pascal where most people use { } for "normal" comments and (* *) to comment out unneeded blocks of code. I have no ideas how this could look though.

On Thu, 17 Jan 2002 20:02:24 +0000, OddesE wrote:

> Yes indeed, what *is* wrong with nested comments? It seems almost no
> language supports it (C/C++, Java, Pascal, HTML, D?) but why? Is it that
> difficult to implement?
> Is it a feature that would easily be misused? Is there something I am
> totally missing?

What about a type of comment which can be nested but which forces you to state explicitly that you are nesting?

For example, say normal comments look like this:
 /* ........ */

Nested comments could have a label at the start which has to correspond to one at the end:

 /*1 ... /*2 .... /*4 ......  .....  4*/  ....  2*/   ....  1*/

Ben Cohen wrote:

> On Thu, 17 Jan 2002 20:02:24 +0000, OddesE wrote:
> 
> 
>>Yes indeed, what *is* wrong with nested comments? It seems almost no
>>language supports it (C/C++, Java, Pascal, HTML, D?) but why? Is it that
>>difficult to implement?
>>Is it a feature that would easily be misused? Is there something I am
>>totally missing?
>>
> 
> What about a type of comment which can be nested but which forces you to
> state explicitly that you are nesting?
> 
> For example, say normal comments look like this:
>  /* ........ */
> 
> Nested comments could have a label at the start which has to correspond
> to one at the end:
> 
>  /*1 ... /*2 .... /*4 ......  .....  4*/  ....  2*/   ....  1*/
> 

Sounds like more complexity to no benefit. It's not hard to
support nesting of /* */ comments in a compiler (change the
parser's are-we-in-a-comment logic to be semantically integer
instead of semantically boolean) -- I present the large number
of C compilers which have offered this as an option over the
years. Nested comments seem unlikely to create obscure errors,
because the file won't compile until you have balanced /* */.
Existing code which has /* /* */ in it should produce an error
message which could hint at the probable cause and solution.
The only downside I can see is that at some point your editor's
syntax highlighting and your compiler's rules might be at odds
as to whether comments are nestable, which would be confusing.

But then, I *never* use /* */ comments when I can use // instead.

-RB

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3C486312.90800@estarcion.com...

> But then, I *never* use /* */ comments when I can use // instead.

Who does? But it happens when I first comment out a 10-line
loop with /* */ (too lazy to use //s for that =)), and then
I want to comment out the entire 100-line function and
have to use #ifdef 0 or remove those nested ones... $#@%

I'd like to take the other side of this argument and say that comments should *not* nest.  Here are my reasons:

    1. D follows the C /* */ comment convention.  Features taken from
    other languages should be kept the same unless there is a d***
    good reason to change them.

    2. Using comments to "comment out" code is not a d*** good reason.
    In fact it's not even a good reason.

    3. For "commenting out" code, I've taken to using

       if(0){ unused code here...    }

    (sometimes without the braces if only one line is being removed).
    It works great!

    4. If you want to do weird things like comment out the last half of
    one function body and the first half of another, shame on you.  The
    language should not be adapted one angstrom to support such nonsense.

    5. Clearly there are cases were the if(0){ ... } style doesn't work.
    So what?  Comments are for commenting programs, not for program
    versioning.  If what's being done is complicated enough so that the
    simple if(0){ ... } form doesn't cover it, then it's complicated
    enough to spend some time and give some thought to what it is that
    needs expressing and how to express it.  It's hard to find something
    worse than code that's gone through iteration after iteration of take
    out this, take out that, meanwhile leaving all the previous code
    version (comments included) present.  As in regular writing, if the
    simple rules don't cover it, rewrite!

Summary:  use comment delimiters to write comments, and only to write comments.  Use other mechanisms (and D has several good ones) to remove obsolete code.  If comment delimiters are used only to write comments, it's better to stick with non-nesting comments.



"OddesE" <OddesE_XYZ@hotmail.com> writes:

> "Pavel Minayev" <evilone@omen.ru> wrote in message news:a0ujps$1iqj$1@digitaldaemon.com...
> > "Walter" <walter@digitalmars.com> wrote in message news:a0tv8q$15rd$1@digitaldaemon.com...
> >
> > > I've been considering making version more tolerant of bad syntax, but it
> > is
> > > going to have to count { and } !
> >
> > Still... what's wrong with nested comments? It's really funny to see that, even though ANSI commitee didn't make them standart, most C++ compilers around have a switch which enables them. It's not so hard to implement, but could be a useful thing!
> >
> 
> Yes indeed, what *is* wrong with nested comments?
> It seems almost no language supports it (C/C++, Java,
> Pascal, HTML, D?) but why?
> Is it that difficult to implement?
> Is it a feature that would easily be misused?
> Is there something I am totally missing?
> 
> Personally I think one of the very big disadvantages of
> all the languages mentioned above is their lack of nested
> comments. It is just so easy to comment out a block of code
> for debugging purposes with the /* and */ comments...I
> never ever use /* and */ for normal comments, because then
> I 'lose' the option to comment out blocks of code. So when
> I write a function header comment, it looks like this:
> 
> // ===================================
> //  Print ([in] char[] string)
> //
> //  DESCRIPTION:   Prints out the string argument to stdout
> //  ARGUMENT:       string:  The string to print
> //  RETURNS:           -
> //  EXCEPTIONS:     -
> // ----------------------------------------------------
> 
> Something like that...
> I would rather want to use /* */ but because they can't
> be nested it causes all kinds of problems, so I avoid
> using them for normal comments at all.
> Worse still, when I get someone elses code, who does
> use /* and */ I am in trouble...
> 
> So I beg you, please make the comments nest...It would
> solve a lot of problems (for me).
> 
> 
> --
> Stijn
> OddesE_XYZ@hotmail.com
> http://www.OddesE.f2s.com
> __________________________________________
> Remove _XYZ from my address when replying by mail

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a29q8c$2l9t$1@digitaldaemon.com...
> "Russell Borogove" <kaleja@estarcion.com> wrote in message news:3C486312.90800@estarcion.com...
>
> > But then, I *never* use /* */ comments when I can use // instead.
>
> Who does? But it happens when I first comment out a 10-line
> loop with /* */ (too lazy to use //s for that =)), and then
> I want to comment out the entire 100-line function and
> have to use #ifdef 0 or remove those nested ones... $#@%

   On the other side, personally, most of the times I comment something out,
I want to put an alternative piece of code. Thanks to the fact that C++ uses
non-nested comments, I can do the following:

---
/*
   Code 1
/*/
   Code 2
//*/
---

   Code 1 is commented out, while Code 2 is not. Then, I can add a forward
slash at the beginning of the first line to uncomment code 1 and comment
code 2. Very useful. Cannot be done with nested comments, though.

   Ideally, D could provide something like:

---
comment(1) {
case 1:
   Code 1
case 2:
   Code 2
}
---

   You'd then be able to change the number (or identifier, or whatever)
inside the comment parenthesis. This would need to have tokenizable contents
within the braces, of course, but no parsing or semantic checks (no matching
of identifiers and such) would need to be done, which makes it perfect for
commenting-out code.

Salutaciones,
                         JCAB

<la7y6nvo@shamko.com> wrote in message news:s7cu1tj4430.fsf@michael.shamko.com...
> I'd like to take the other side of this argument and say that comments should *not* nest.  Here are my reasons:
>
>     1. D follows the C /* */ comment convention.  Features taken from
>     other languages should be kept the same unless there is a d***
>     good reason to change them.

D has quite a lot of changes from C. Just to remember syntax used to declare pointers...

>     2. Using comments to "comment out" code is not a d*** good reason.
>     In fact it's not even a good reason.

A debateful statement it is.

>     3. For "commenting out" code, I've taken to using
>
>        if(0){ unused code here...    }
>
>     (sometimes without the braces if only one line is being removed).
>     It works great!

Try to comment out a function like that!

>     4. If you want to do weird things like comment out the last half of
>     one function body and the first half of another, shame on you.  The
>     language should not be adapted one angstrom to support such nonsense.

Why not, if it's a practical situation?

>     5. Clearly there are cases were the if(0){ ... } style doesn't work.
>     So what?  Comments are for commenting programs, not for program
>     versioning.  If what's being done is complicated enough so that the
>     simple if(0){ ... } form doesn't cover it, then it's complicated
>     enough to spend some time and give some thought to what it is that
>     needs expressing and how to express it.  It's hard to find something
>     worse than code that's gone through iteration after iteration of take
>     out this, take out that, meanwhile leaving all the previous code
>     version (comments included) present.  As in regular writing, if the
>     simple rules don't cover it, rewrite!

I don't leave the code present. I might start doing it one way, then understand that there _might_ be a better one... so I comment out what I have, implement it in the "better" way, and either remove the comment or the new code depending on whether it works or not.

"Juan Carlos Arevalo Baeza" <jcab@roningames.com> wrote in message news:a2afk9$2ia$1@digitaldaemon.com...

>    On the other side, personally, most of the times I comment something
out,
> I want to put an alternative piece of code. Thanks to the fact that C++
uses
> non-nested comments, I can do the following:
>
> ---
> /*
>    Code 1
> /*/
>    Code 2
> //*/
> ---
>
>    Code 1 is commented out, while Code 2 is not. Then, I can add a forward
> slash at the beginning of the first line to uncomment code 1 and comment
> code 2. Very useful. Cannot be done with nested comments, though.

Never thought of it... a nice trick!
Well... looks like a draw =)

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a2ag5i$30n$1@digitaldaemon.com...

> "Juan Carlos Arevalo Baeza" <jcab@roningames.com> wrote in message news:a2afk9$2ia$1@digitaldaemon.com...
> >
> > ---
> > /*
> >    Code 1
> > /*/
> >    Code 2
> > //*/
> > ---
>
> Never thought of it... a nice trick!

   :) I couldn't believe it when I found it...

> Well... looks like a draw =)

   My point was... it needs not be. We're abusing the comment feature of the
language for a purpose for which it was not designed. Instead, the language
should provide an appropriate way to do it. Like above.

   It already does, actually: version {} Only it'd be nice to be able to
specify sub-blocks and select one for uncommenting, all in the same place.
Maybe there's a way, I haven't really played with it much.

Salutaciones,
                         JCAB

In response to the dicussion between la7y6nvo and
Pavel, I would like to add some more points...


"Pavel Minayev" <evilone@omen.ru> wrote in message news:a2afp4$2ji$1@digitaldaemon.com...
> <la7y6nvo@shamko.com> wrote in message news:s7cu1tj4430.fsf@michael.shamko.com...
> > I'd like to take the other side of this argument and say that comments should *not* nest.  Here are my reasons:
> >
> >     1. D follows the C /* */ comment convention.  Features taken from
> >     other languages should be kept the same unless there is a d***
> >     good reason to change them.
>
> D has quite a lot of changes from C. Just to remember syntax used to declare pointers...

Nesting comments is a very small change, that is immediately
obvious when you try to misuse it, and therefore doesn't form
a huge obstacle. Furthermore, people programming in D will
have to learn D anyhow, because there are a lot of things that
have changed significantly. I agree that changing something just
a little bit should have a very good reason, but I personally
think including nested comments is.


> >     2. Using comments to "comment out" code is not a d*** good reason.
> >     In fact it's not even a good reason.
>
> A debateful statement it is.
>

Definitely. I personally do it all the time, and so do most other programmers I know. It is just very convenient.


> >     3. For "commenting out" code, I've taken to using
> >
> >        if(0){ unused code here...    }
> >
> >     (sometimes without the braces if only one line is being removed).
> >     It works great!
>
> Try to comment out a function like that!
>

There is a big difference between these two methods. When I
comment out code, I *remove* that code from the program.
When you use the if (0) technique you just make sure it does
not run. Worse still, another programmer is going to have a hard
time trying to figure out why you wrote a piece of code that
is never going to be executed. It is very obvious that if code
is commented out, it probably was replaced by other code, or
is no longer neccesary.


> >     4. If you want to do weird things like comment out the last half of
> >     one function body and the first half of another, shame on you.  The
> >     language should not be adapted one angstrom to support such
nonsense.
>
> Why not, if it's a practical situation?
>

That would be a wierd situation, but you can already
easily do that without nested comments...The language
doesn't have to be adapted at all, it already supports
such 'nonsense'!


> >     5. Clearly there are cases were the if(0){ ... } style doesn't work.
> >     So what?  Comments are for commenting programs, not for program
> >     versioning.  If what's being done is complicated enough so that the
> >     simple if(0){ ... } form doesn't cover it, then it's complicated
> >     enough to spend some time and give some thought to what it is that
> >     needs expressing and how to express it.  It's hard to find something
> >     worse than code that's gone through iteration after iteration of
take
> >     out this, take out that, meanwhile leaving all the previous code
> >     version (comments included) present.  As in regular writing, if the
> >     simple rules don't cover it, rewrite!
>
> I don't leave the code present. I might start doing it one way, then understand that there _might_ be a better one... so I comment out what I have, implement it in the "better" way, and either remove the comment or the new code depending on whether it works or not.
>

Definitely! Or trying to find out if a piece of code causes a bug by commenting it out, or rewriting a function for efficiency without throwing it away.


But there is one big point that la7y6nvo is making that I wholeheartedly agree with:

>>Comments are for commenting programs, not
>>for program versioning.

Totally agreed! Comments where designed with the
purpose of commenting on what you are doing in a
piece of code.

However, practice has shown that programmers want
a way to easily remove pieces of code from a program,
without actually totally removing it from the source text.
Maybe there should indeed be introduced a new type
of 'comments' (or should I say removers?), that do nest.
They could be highlighted with a different color in the
editor, and then /* */ would be restored to it's original
purpose, commenting on code.

At the moment, most experienced programmers avoid
using /* */ altogether, even when it's use would be very
practical, to keep the option of using them for
commenting out pieces of code.

I am for simply nesting the existing /* */, but another
way of 'removing' code would be good to.


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
__________________________________________
Remove _XYZ from my address when replying by mail