Hi,

Seeing that the following use of comments is very common:

#ifndef _BLA_H_

while (1)
{
   ...
  for(;;)
  {
     ..
  } // for
} // while

#endif // _BLA_H_

Perhaps this could be unenforced by the compiler. For instance:

version(Windows)
{

void doit(int i)
{
  while(i > 0)
  {
     ...
    do lot of stuff();
     ...
  }(while)
}(doit)

}(version)

What do you think? I tend to avoid these kinds of comments, but for those who use them and for those situations where they are really necessary it would be a lot better to have a compiler enforce it than to have a commentary that might even be incorrect.

Better syntaxes could be invented, I just wanted an opinion on the gist idea.


Luís

Luís Marques wrote:
> Hi,
> 
> Seeing that the following use of comments is very common:
> 
> #ifndef _BLA_H_
> 
> while (1)
> {
>    ...
>   for(;;)
>   {
>      ..
>   } // for
> } // while
> 
> #endif // _BLA_H_
> 
> Perhaps this could be unenforced by the compiler. For instance:
> 
> version(Windows)
> {
> 
> void doit(int i)
> {
>   while(i > 0)
>   {
>      ...
>     do lot of stuff();
>      ...
>   }(while)
> }(doit)
> 
> }(version)
> 
> What do you think? I tend to avoid these kinds of comments, but for those who use them and for those situations where they are really necessary it would be a lot better to have a compiler enforce it than to have a commentary that might even be incorrect.
> 
> Better syntaxes could be invented, I just wanted an opinion on the gist idea.
> 
> 
> Luís

Personally I do prefer keeping them as comments, as they serve primarily as a visual cue in really long functions/classes/structs for me.  (And I like to keep things like this "green" in my editor. :))  Although, that said, in a scripting language idea I toyed around with, I did have this as an option, such as:

# function doit (Int $i) begin
#   while ($i > 0) begin
#     ...do lot of stuff...
#   end while
# end doit

Ordinarily it uses {}'s but I put the begin/end[name] thing in there.  I just don't think it would be very "D like".

-- Chris Nicholson-Sauls

They can be useful if you have a lot of stuff in between. But they are annoying if there is only one line in between.

Another idea: if you have such a lot of stuff in inner control structures, move it into a private or nested functions. Then get rid of these comments :)

Frank Benoit (keinfarbton) wrote:
> They can be useful if you have a lot of stuff in between. But they are
> annoying if there is only one line in between.
> 
> Another idea: if you have such a lot of stuff in inner control
> structures, move it into a private or nested functions. Then get rid of
> these comments :)

Yes, that's what I would recommend.
But there really are  some kinds of blocks that may be large by design (e.g. version statements, classes, etc).

== Quote from Chris Nicholson-Sauls (ibisbasenji@gmail.com)'s article
> Luís Marques wrote:
> > Better syntaxes could be invented, I just wanted an opinion on the gist idea.
> >
> >
> > Luís
> Personally I do prefer keeping them as comments, as they serve primarily as a
visual cue
> in really long functions/classes/structs for me.  (And I like to keep things
like this
> "green" in my editor. :))  Although, that said, in a scripting language idea I toyed
> around with, I did have this as an option, such as:
> # function doit (Int $i) begin
> #   while ($i > 0) begin
> #     ...do lot of stuff...
> #   end while
> # end doit
> Ordinarily it uses {}'s but I put the begin/end[name] thing in there.  I just
don't think
> it would be very "D like".
> -- Chris Nicholson-Sauls


While it may not be very "D like", it sure makes the code MUCH more readable and
"nicer" looking IMO.  VASTLY better than the meaningless and hideous curly braces.
 Especially when there is a LOT of ...stuff... and nesting going on.  Ideally, I
think it should go one step further, with the compiler automatically putting in
the comments after the End statements. Like this...


# function doit (Int $i) begin
#   while ($i > 0) begin
#     ...do lot of stuff...
#   end while  // ($i > 0)
# end doit  // (Int $i)

Of course, I'm not biased or anything... :)

What might be the most useful would be for the compiler to check for a comment at the end of a block and if it clams to close a block that it doesn't, emit a warning.


//////these pass


for(int i=0;i<10;i++){
	...
}//CLOSE for i

while(j<k){
	...
}/*CLOSE while j < k this block has more comments */

outer: switch(n){
	...
}/+CLOSE outer: +/


//////these fail


inner: switch(n){
	...
}//CLOSE outer:

for(int i=0;i<10;i++){
	...
}//CLOSE for j

BCS wrote:
> What might be the most useful would be for the compiler to check for a comment at the end of a block and if it clams to close a block that it doesn't, emit a warning.
> 
> 
> //////these pass
> 
> 
> for(int i=0;i<10;i++){
>     ...
> }//CLOSE for i
> 
> while(j<k){
>     ...
> }/*CLOSE while j < k this block has more comments */
> 
> outer: switch(n){
>     ...
> }/+CLOSE outer: +/
> 
> 
> //////these fail
> 
> 
> inner: switch(n){
>     ...
> }//CLOSE outer:
> 
> for(int i=0;i<10;i++){
>     ...
> }//CLOSE for j

Now that's actually not a bad idea.  Keeps it "green" when editing, remains optional, and provides more than just the visual cue (if the compiler in use supports it).  Might've been useful in some of the more convoluted things I've written (like a few parsers/lexers with insane nesting).

-- Chris Nicholson-Sauls

Chris Nicholson-Sauls wrote:
> BCS wrote:
>> What might be the most useful would be for the compiler to check for a comment at the end of a block and if it clams to close a block that it doesn't, emit a warning.
>>
>>
>> //////these pass
>>
>>
>> for(int i=0;i<10;i++){
>>     ...
>> }//CLOSE for i
>>
>> while(j<k){
>>     ...
>> }/*CLOSE while j < k this block has more comments */
>>
>> outer: switch(n){
>>     ...
>> }/+CLOSE outer: +/
>>
>>
>> //////these fail
>>
>>
>> inner: switch(n){
>>     ...
>> }//CLOSE outer:
>>
>> for(int i=0;i<10;i++){
>>     ...
>> }//CLOSE for j
> 
> Now that's actually not a bad idea.  Keeps it "green" when editing, remains optional, and provides more than just the visual cue (if the compiler in use supports it).  Might've been useful in some of the more convoluted things I've written (like a few parsers/lexers with insane nesting).
> 
> -- Chris Nicholson-Sauls

Having the compiler care about contents of a comment is a dangerous slippery slope.  If you want to do this in some sort of a lint-esque tool, then go for it, I guess.

Later,
Brad

Brad Roberts wrote:
> 
> 
> Having the compiler care about contents of a comment is a dangerous slippery slope.  If you want to do this in some sort of a lint-esque tool, then go for it, I guess.
> 
> Later,
> Brad

I considered peppering my post with some sort of joke about de-linting programs.

Maybe DMD should add a "-l" option for "run Lint checks", like nesting checks.

Brad Roberts wrote:
> Having the compiler care about contents of a comment is a dangerous slippery slope.  If you want to do this in some sort of a lint-esque tool, then go for it, I guess.

Well, if you are having the compiler "lint" the code that it would probably be best if it just checked for coherent indentation.

E.g.

if(bla)
  do1();
  do2(); // lint warning/error! (inconsistent syntax/indentation)
else
  do3();