www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Block close check

reply =?ISO-8859-1?Q?Lu=EDs_Marques?= <luismarques+spam gmail.com> writes:
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
Dec 09 2006
next sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
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
Dec 09 2006
parent Wolven <rma wolven.net> writes:
== 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


 in really long functions/classes/structs for me.  (And I like to keep things

 "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

 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... :)
Dec 10 2006
prev sibling next sibling parent reply "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
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 :)
Dec 10 2006
parent =?UTF-8?B?THXDrXMgTWFycXVlcw==?= <luismarques+spam gmail.com> writes:
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).
Dec 10 2006
prev sibling parent reply BCS <BCS pathlink.com> writes:
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
Dec 11 2006
next sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
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
Dec 11 2006
next sibling parent BCS <BCS pathlink.com> writes:
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.
Dec 11 2006
prev sibling next sibling parent =?ISO-8859-1?Q?Lu=EDs_Marques?= <luismarques+spam gmail.com> writes:
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();
Dec 11 2006
prev sibling parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Brad Roberts wrote:
 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

Generally true... And probably would be the better way to go. We do, however, have some minor precedant in DMD's DDoc feature which is based entirely in comments. ;) Granted that's already proven a little dangerous, but useful. -- Chris Nicholson-Sauls
Dec 11 2006
prev sibling parent Brad Roberts <braddr puremagic.com> writes:
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
Dec 11 2006