www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - nested comments

reply %u <asmasm hotmail.com> writes:
what is the purpose of nested comments ?
May 30 2011
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
I use them when commenting out code or when writing documentation
examples. (which may have comments nested inside the doc comment)

Commenting out code is the purpose in general though.
May 30 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-05-30 14:21, Adam D. Ruppe wrote:
 I use them when commenting out code or when writing documentation
 examples. (which may have comments nested inside the doc comment)
 
 Commenting out code is the purpose in general though.

Yeah, it's really annoying to comment out code with /* */ when it already contains comments which used /* */. /+ +/ doesn't have that problem thanks to the nesting, and it's fantastic. /++ +/ can be used for ddoc comments, but beyond that, I don't generally use /+ +/ for actual comments. It's real usefulness is in commenting out code. - Jonathan M Davis
May 30 2011
parent reply %u <asmasm hotmail.com> writes:
commenting out code?? example please
May 30 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
 commenting out code?? example please

/+ /* this is code: */ int more_code; // more code code(more_code+even_more_code(1321)); +/
May 30 2011
parent %u <asmasm hotmail.com> writes:
I understand it
thanks
May 30 2011
prev sibling next sibling parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
%u Wrote:

 what is the purpose of nested comments ?

The purpose is commenting out code, but note that there is also version(none) { } which is never compiled in.
May 30 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Jesse Phillips:

 The purpose is commenting out code, but note that there is also version(none)
{ } which is never compiled in.

version(none) {} is probably the official way to comment out code. And if you use a versioning system to keep your code, then commenting out code is not a so wise thing to do. Bye, bearophile
May 30 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:is1dj6$ihb$1 digitalmars.com...
 Jesse Phillips:

 The purpose is commenting out code, but note that there is also 
 version(none) { } which is never compiled in.

version(none) {} is probably the official way to comment out code. And if you use a versioning system to keep your code, then commenting out code is not a so wise thing to do.

Why not? I've never heard of a VCS that went around stripping out all comments.
May 30 2011
next sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
On 5/31/11 7:58 AM, Nick Sabalausky wrote:
 "bearophile"<bearophileHUGS lycos.com>  wrote in message
 news:is1dj6$ihb$1 digitalmars.com...
 Jesse Phillips:

 The purpose is commenting out code, but note that there is also
 version(none) { } which is never compiled in.

version(none) {} is probably the official way to comment out code. And if you use a versioning system to keep your code, then commenting out code is not a so wise thing to do.

Why not? I've never heard of a VCS that went around stripping out all comments.

The question is: why comment and commit code that you can already find in the commit history? Then you end up with huge files with things like: /* * Maybe we will use this in a future, this is not working right now ... ... ... */ and the code becomes a mess. So I agree with bearophile here.
May 30 2011
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Ary Manzana" <ary esperanto.org.ar> wrote in message 
news:is1hsa$p53$1 digitalmars.com...
 On 5/31/11 7:58 AM, Nick Sabalausky wrote:
 "bearophile"<bearophileHUGS lycos.com>  wrote in message
 news:is1dj6$ihb$1 digitalmars.com...
 Jesse Phillips:

 The purpose is commenting out code, but note that there is also
 version(none) { } which is never compiled in.

version(none) {} is probably the official way to comment out code. And if you use a versioning system to keep your code, then commenting out code is not a so wise thing to do.

Why not? I've never heard of a VCS that went around stripping out all comments.

The question is: why comment and commit code that you can already find in the commit history? Then you end up with huge files with things like: /* * Maybe we will use this in a future, this is not working right now ... ... ... */ and the code becomes a mess. So I agree with bearophile here.

But that applies to version(none) {}, too. Maybe I misunderstood bearophile, I thought he meant "if you use a versioning system to keep your code, then commenting out code [as opposed to using version(none) {}] is not a so wise thing to do"
May 30 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-05-30 19:53, Nick Sabalausky wrote:
 "Ary Manzana" <ary esperanto.org.ar> wrote in message
 news:is1hsa$p53$1 digitalmars.com...
 
 On 5/31/11 7:58 AM, Nick Sabalausky wrote:
 "bearophile"<bearophileHUGS lycos.com>  wrote in message
 news:is1dj6$ihb$1 digitalmars.com...
 
 Jesse Phillips:
 The purpose is commenting out code, but note that there is also
 version(none) { } which is never compiled in.

version(none) {} is probably the official way to comment out code. And if you use a versioning system to keep your code, then commenting out code is not a so wise thing to do.

Why not? I've never heard of a VCS that went around stripping out all comments.

The question is: why comment and commit code that you can already find in the commit history? Then you end up with huge files with things like: /* * Maybe we will use this in a future, this is not working right now ... ... ... */ and the code becomes a mess. So I agree with bearophile here.

But that applies to version(none) {}, too. Maybe I misunderstood bearophile, I thought he meant "if you use a versioning system to keep your code, then commenting out code [as opposed to using version(none) {}] is not a so wise thing to do"

I'm not sure what he meant. Personally, I don't see much value to version(none). I believe that the only gain that you get out of it is that the code must be syntactically correct. And since the code is never going to be used until you change the version, I don't really see much value in that. Comments do the job just as well. - Jonathan M Davis
May 30 2011
prev sibling parent Jose Armando Garcia <jsancio gmail.com> writes:
On Mon, May 30, 2011 at 11:58 PM, Jonathan M Davis <jmdavisProg gmx.com> wr=
ote:
 On 2011-05-30 19:53, Nick Sabalausky wrote:
 "Ary Manzana" <ary esperanto.org.ar> wrote in message
 news:is1hsa$p53$1 digitalmars.com...

 On 5/31/11 7:58 AM, Nick Sabalausky wrote:
 "bearophile"<bearophileHUGS lycos.com> =A0wrote in message
 news:is1dj6$ihb$1 digitalmars.com...

 Jesse Phillips:
 The purpose is commenting out code, but note that there is also
 version(none) { } which is never compiled in.

version(none) {} is probably the official way to comment out code. And if you use a versioning system to keep your code, then commentin=





 out
 code is not a so wise thing to do.

Why not? I've never heard of a VCS that went around stripping out all comments.

The question is: why comment and commit code that you can already find=



 the commit history? Then you end up with huge files with things like:

 /*

 =A0* Maybe we will use this in a future, this is not working right now
 =A0...
 =A0...
 =A0...
 =A0*/

 and the code becomes a mess.

 So I agree with bearophile here.

But that applies to version(none) {}, too. Maybe I misunderstood bearophile, I thought he meant "if you use a versioning system to keep your code, then commenting out code [as opposed to using version(none) {=


 is not a so wise thing to do"

I'm not sure what he meant. Personally, I don't see much value to version(none). I believe that the only gain that you get out of it is tha=

 code must be syntactically correct. And since the code is never going to =

 used until you change the version, I don't really see much value in that.
 Comments do the job just as well.

 - Jonathan M Davis

Use static if(false) the compiler makes sure that code still compiles at least. The problem with commented out code being saved in common code repositories is that it can suffer from bit rust.
May 31 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-05-30 18:52, Ary Manzana wrote:
 On 5/31/11 7:58 AM, Nick Sabalausky wrote:
 "bearophile"<bearophileHUGS lycos.com>  wrote in message
 news:is1dj6$ihb$1 digitalmars.com...
 
 Jesse Phillips:
 The purpose is commenting out code, but note that there is also
 version(none) { } which is never compiled in.

version(none) {} is probably the official way to comment out code. And if you use a versioning system to keep your code, then commenting out code is not a so wise thing to do.

Why not? I've never heard of a VCS that went around stripping out all comments.

The question is: why comment and commit code that you can already find in the commit history? Then you end up with huge files with things like: /* * Maybe we will use this in a future, this is not working right now ... ... ... */ and the code becomes a mess. So I agree with bearophile here.

I'd say that most people would consider it to be bad ediquette to commit commented out code to a repository in most cases. The VCS does allow you to get at old code if you need to. So, commenting out code is generally for development purposes only. However, there _are_ occasionally cases where it makes sense to comment out code and check it in that way - such as when a compiler bug makes a unit test fail, and it doesn't make sense to be running the test until the compiler bug is fixed. std.array has a few functions which were added as commented out, because they can't actually be added until some of its other functions have been deprecated and removed (since they share the same name but different behavior - e.g. insert is being replaced by insertInPlace, and the version of insert which doesn't insert in place can't be added to std.array until the original insert is gone). But it makes good sense for the implementations to be there, ready to be put into service as soon the old functions are gone, so they're there but comment out. In most cases, however, you shouldn't be checking in commented code. It just makes for messier code and most people consider it to be bad etiquette. - Jonathan M Davis
May 30 2011
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:

 What _is_ a bad idea is leaving in sections of commented out code when you
check in code.<

Right, that's what I meant. Commenting out parts is fine while you are fixing or writing code. Bye, bearophile
May 30 2011
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.vwcxmwfgeav7ka localhost.localdomain...
 On Mon, 30 May 2011 20:43:18 -0400, bearophile <bearophileHUGS lycos.com> 
 wrote:

 Jesse Phillips:

 The purpose is commenting out code, but note that there is also 
 version(none) { } which is never compiled in.

version(none) {} is probably the official way to comment out code. And if you use a versioning system to keep your code, then commenting out code is not a so wise thing to do.

I would add that there is a huge difference between version(none) and commenting -- version(none) code must still parse, whereas commenting out code is more flexible. For example: for(int i = 0; i < 100; i++) if(x == i) { writeln("found x") if(y == i) writeln("x and y are the same!"); } if you want to just comment out the if(x == i) line, using version(none) is not going to work well. I would say that commenting out to test things is acceptable, but version(none) should be used when code is to be turned off long-term.

I prefer comments even for longer term. That way, it always gets highlighted as "THIS CODE IS NOT ACTIVE" and doesn't end up confusing me.
May 31 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-05-30 17:43, bearophile wrote:
 Jesse Phillips:
 The purpose is commenting out code, but note that there is also
 version(none) { } which is never compiled in.

version(none) {} is probably the official way to comment out code. And if you use a versioning system to keep your code, then commenting out code is not a so wise thing to do.

There's absolutely nothing wrong with commenting out code. I do it all the time when working on code. It's extremely useful to do so. /+ +/ is _extremely_ useful, and there's absolutely nothing wrong with using it. What _is_ a bad idea is leaving in sections of commented out code when you check in code. - Jonathan M Davis
May 30 2011
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 30 May 2011 20:43:18 -0400, bearophile <bearophileHUGS lycos.com>  
wrote:

 Jesse Phillips:

 The purpose is commenting out code, but note that there is also  
 version(none) { } which is never compiled in.

version(none) {} is probably the official way to comment out code. And if you use a versioning system to keep your code, then commenting out code is not a so wise thing to do.

I would add that there is a huge difference between version(none) and commenting -- version(none) code must still parse, whereas commenting out code is more flexible. For example: for(int i = 0; i < 100; i++) if(x == i) { writeln("found x") if(y == i) writeln("x and y are the same!"); } if you want to just comment out the if(x == i) line, using version(none) is not going to work well. I would say that commenting out to test things is acceptable, but version(none) should be used when code is to be turned off long-term. -Steve
May 31 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-05-31 18:03, Nick Sabalausky wrote:
 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
 news:op.vwcxmwfgeav7ka localhost.localdomain...
 
 On Mon, 30 May 2011 20:43:18 -0400, bearophile <bearophileHUGS lycos.com>
 
 wrote:
 Jesse Phillips:
 The purpose is commenting out code, but note that there is also
 version(none) { } which is never compiled in.

version(none) {} is probably the official way to comment out code. And if you use a versioning system to keep your code, then commenting out code is not a so wise thing to do.

I would add that there is a huge difference between version(none) and commenting -- version(none) code must still parse, whereas commenting out code is more flexible. For example: for(int i = 0; i < 100; i++) if(x == i) { writeln("found x") if(y == i) writeln("x and y are the same!"); } if you want to just comment out the if(x == i) line, using version(none) is not going to work well. I would say that commenting out to test things is acceptable, but version(none) should be used when code is to be turned off long-term.

I prefer comments even for longer term. That way, it always gets highlighted as "THIS CODE IS NOT ACTIVE" and doesn't end up confusing me.

I honestly don't get the point of version(none). Sure, you get syntactic analysis, but what good is that really? The code is still subject to bit-rot. You're still going to have to make sure that it's valid if and when you enable it again. Comments do just as good a job. All you lose is syntactic analysis and syntactic highlighting. And I don't see much point in either for totally inactive code. - Jonathan M Davis
May 31 2011