digitalmars.D - Block close check

=?ISO-8859-1?Q?Lu=EDs_Marques?= (32/32) Dec 09 2006 Hi,

Chris Nicholson-Sauls (13/57) Dec 09 2006 Personally I do prefer keeping them as comments, as they serve primarily...

Wolven (15/33) Dec 10 2006 like this

Frank Benoit (keinfarbton) (5/5) Dec 10 2006 They can be useful if you have a lot of stuff in between. But they are

=?UTF-8?B?THXDrXMgTWFycXVlcw==?= (4/10) Dec 10 2006 Yes, that's what I would recommend.

BCS (20/20) Dec 11 2006 What might be the most useful would be for the compiler to check for a

Chris Nicholson-Sauls (6/37) Dec 11 2006 Now that's actually not a bad idea. Keeps it "green" when editing, rema...

Brad Roberts (6/46) Dec 11 2006 Having the compiler care about contents of a comment is a dangerous

BCS (5/13) Dec 11 2006 I considered peppering my post with some sort of joke about de-linting
=?ISO-8859-1?Q?Lu=EDs_Marques?= (9/12) Dec 11 2006 Well, if you are having the compiler "lint" the code that it would
Chris Nicholson-Sauls (5/53) Dec 11 2006 Generally true... And probably would be the better way to go. We do, h...

=?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

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:







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

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

 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:





 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...








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

Dec 10 2006

"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

=?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

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

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

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

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

=?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

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

D Programming

C/C++ Programming

Other

digitalmars.D - Block close check