Carlos Santander B. wrote:
> "J Anderson" <REMOVEanderson@badmama.com.au> wrote in message
> news:bv17ej$eim$1@digitaldaemon.com...
> | Yeah, C doesn't even have /* */.
> |
> | --
> | -Anderson: http://badmama.com.au/~anderson/
> 
> Wrong there: /* */ is the only way to comment C code.
> 
> -----------------------
> Carlos Santander Bernal

I sure hope a person doesn't to be an expert in C, C++, Java, and all varieties of Pascal (ANSI, Turbo, & Delphi) in order to discuss things around here.

I was thinking that /* */ and // were fair game for commenting in C, C++, and Java. I guess not. (Maybe it depends on how compliant the compiler is.)

I didn't realize until it was brought up the other day that Turbo Pascal allows { } to be nested. (ANSI Pascal apparently doesn't, but who follows that standard anyway?)

I personally like the way commenting occurs in D. I'm not aware of another language that is so flexible that there are three distinct types of commenting. And with all of the contract-by-design goodies we shouldn't need as many comments, right?

I learned how fancy comments worked in D from playing around with the compiler, and made up some examples of how it works in some more complicated cases (http://jcc_7.tripod.com/d/tutor/).

-- 
Justin
http://jcc_7.tripod.com/d/

Carlos Santander B. wrote:

>"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message
>news:bv17ej$eim$1@digitaldaemon.com...
>| Yeah, C doesn't even have /* */.
>|
>| --
>| -Anderson: http://badmama.com.au/~anderson/
>
>Wrong there: /* */ is the only way to comment C code.
>
>-----------------------
>Carlos Santander Bernal
>
>
>  
>
I must have been tired. Whoops.

-- 
-Anderson: http://badmama.com.au/~anderson/

J C Calvarese schrieb:

[...]
> I learned how fancy comments worked in D from playing around with the compiler, and made up some examples of how it works in some more complicated cases (http://jcc_7.tripod.com/d/tutor/).

However, your example comments in the comments-part are wrong. /*- and //-comments do not nest, they are broken.

So long.

Manfred Nowak wrote:
> J C Calvarese schrieb:
> [...]
>>more complicated cases (http://jcc_7.tripod.com/d/tutor/).
> 
> 
> However, your example comments in the comments-part are wrong. /*- and //-comments do not nest, they are broken.

You're right. My example was misleading. Since you brought this to my attention, I tried to make it more clear.

I think this might be something that is difficult to teach, so hopefully people can make use of my example as a place to start until I can figure out how to explain it better.

> 
> So long.


-- 
Justin
http://jcc_7.tripod.com/d/

J C Calvarese wrote:

[...]
> I think this might be something that is difficult to teach
[...]

Because it is said, that it is easy to implement, it should be also be easy to teach: do not mix the different sorts of comments, hold them separated. Use comments for commenting, not for commenting out code.

If trial code is supposed to be put out of work, then use

version(trialcode){
   ...
};

In the rare circumstances, when `version(trialcode)' does not work, the use `/+'-comments with extreme care, beware of `/+' and `+/' in included strings, `/*'- and `//'-comments.

The Style guide should be changed accordingly.

So long.

Manfred Nowak wrote:

>J C Calvarese wrote:
>
>[...]
>  
>
>>I think this might be something that is difficult to teach
>>    
>>
>[...]
>
>Use comments for commenting, not for commenting out code.
>
>If trial code is supposed to be put out of work, then use
>
>version(trialcode){
>   ...
>};
>
>
>  
>
Personally I don't subscribe to this theory.  When your commenting out code to debug something often it's only going to be commented out short term (ie 60 seconds, a few days).  It's not a good idea to waste time putting in version(trialcode) { } when your only going to delete that anyway - waste of time.  Most readers will know what you mean when you comment out a block of code.

I due version state for debugging and profiling code however. But debugging code stays in the code much like unittests.

-- 
-Anderson: http://badmama.com.au/~anderson/

J Anderson wrote:
> Manfred Nowak wrote:
> 
>> J C Calvarese wrote:
>>
>> [...]
>>  
>>
>>> I think this might be something that is difficult to teach
>>>   
>>
>> [...]
>>
>> Use comments for commenting, not for commenting out code.
>>
>> If trial code is supposed to be put out of work, then use
>>
>> version(trialcode){
>>   ...
>> };
>>
>>
>>  
>>
> Personally I don't subscribe to this theory.  When your commenting out code to debug something often it's only going to be commented out short term (ie 60 seconds, a few days).  It's not a good idea to waste time putting in version(trialcode) { } when your only going to delete that anyway - waste of time.  Most readers will know what you mean when you comment out a block of code.
> 
> I due version state for debugging and profiling code however. But debugging code stays in the code much like unittests.
> 

if i might just interject my newbie $.02 here.. It is my opinion that a comment should be done in one way only, this avoids confusion and is easy to teach to anyone.

// <comment> EOL

simple, yet managable  :)

It seems to me as if alot of this other stuff is added to make it easier for people using notepad type editors to code with. I feel it should be an IDE's job for selecting and commenting a block of code. If someone wishes to use a simpler editor they should have to just deal with it, the way it is. Hardcore is supposed to be hard isnt it  ;)