February 11, 2009 at 10:37 am
Wow. I didn't see that coming. AND I learned something new! And that's always a good thing. 😀
February 11, 2009 at 10:46 am
Irish Flyer (2/11/2009)
Given the inconsistancies noted, I guess it brings home the point that one should be consistant in coding. Either use the -- convention to comment a line, or use /* */ pairs for comments, but don't mix them. Consistancy is just good coding practice anyway.
I'm pretty consistent about commenting out comment blocks (--/* and --*/). It's the best way to remember which code was in the original block.
February 11, 2009 at 11:08 am
It's the best way to remember which code was in the original block.
I thought that is what version control is for?
February 11, 2009 at 11:14 am
Here are a couple of articles related to this thread:
"Worst Practice - Bad Comments", By Andy Warren, 2003/01/23:
http://www.sqlservercentral.com/articles/Miscellaneous/worstpracticebadcomments/893/
"The case against using single-line comments", By Cade Bryant, 2003/01/22:
February 11, 2009 at 11:27 am
Myles Sigal (2/11/2009)
It's the best way to remember which code was in the original block.
I thought that is what version control is for?
Version control isn't needed when making temporary edits for effect.
Also - version control applications are not a good fit for every shop or project. Sometimes version control is whatever you are savvy enough to remember to update.
February 11, 2009 at 11:34 am
I got it right, but now I realize it was almost by accident.
Irish Flyer (2/11/2009)
Given the inconsistancies noted, I guess it brings home the point that one should be consistant in coding. Either use the -- convention to comment a line, or use /* */ pairs for comments, but don't mix them. Consistancy is just good coding practice anyway.
Good point. I tend to use the comments differently: -- to explain what (I think) the code is doing, /* */ to take out copies of code while I'm messing with it in development or to separate queries I use for testing. Most of the code in /* */ will get taken out in production.
As far as inline comments - I avoid them precisely for the reasons stated above. I do add them to large queries sometimes if I feel that parts of it need to be explained separately. Maybe I ought to exercise more caution in the future.
February 11, 2009 at 11:45 am
I love using inline comments. Especially when hacking complex sql.
For example:
with something like this, I can switch things up using simple inline comments
select a
,b
-- ,c
,d
from taba
,tabb
-- ,tabc
,tabd
where 1=1
and blah-a
--and a = 9
and a = 18
--and a in(1,2,3,4,5)
and blan-b
--and blah-c
and blah-d
February 11, 2009 at 11:58 am
The comments Jesse refers to above are right on point. The problem with Grasshopper's in-line comments example is that too often they get left in the code when it is placed in production. When I do code reviews (and yes, we actually do them), code with those types of comments would be rejected.
February 11, 2009 at 12:45 pm
Let me see if I can show what is going on here and why. Lets number the lines
(00) PRINT '1' -- /* ;PRINT '2' */ ;PRINT '3' /*
(01) PRINT '4' --*/
(02) --/*
(03) PRINT '5'
(04) --*/
(05) /*
(06) PRINT '6'
(07) --/*
(08) */
(09) PRINT '7'
(10) --*/
(11) PRINT '8'
Line (00) has an inline comment starting with the double dash so 2 an 3 are in the comment
Same for (01) so 4 does print just like 1.
Line (02) has an inline comment so the block comment starter is par of the comment and is ignored. Same for (04) and (10).
Line (03) is not in any comment and gets executed. Same goes for line (11).
Line (05) starts a block comment. Lines (06) and (07) are part of the block comment.
Line (08) stops the block comment.
ATBCharles Kincaid
February 11, 2009 at 1:09 pm
Charles,
Regarding line (10). That is the same incorrect assumption that most of us made. Line 10 is not ignored. The comment begin marker causes the parser to search from the bottom up for a comment end marker, and finds it on line (10).
Try this:
/*
Good comment.
--*/
Now my question is why isn't the following just as good.
/*
Good comment not.
--/**/
heh
February 11, 2009 at 2:57 pm
Good point. But then
/*
Good comment not.
-/**/*/
does work. Does this remind you of the Perl parser?
ATBCharles Kincaid
February 11, 2009 at 3:05 pm
Charles Kincaid (2/11/2009)
Let me see if I can show what is going on here and why. Lets number the lines
(00) PRINT '1' -- /* ;PRINT '2' */ ;PRINT '3' /*
(01) PRINT '4' --*/
(02) --/*
(03) PRINT '5'
(04) --*/
(05) /*
(06) PRINT '6'
(07) --/*
(08) */
(09) PRINT '7'
(10) --*/
(11) PRINT '8'
Line (00) has an inline comment starting with the double dash so 2 an 3 are in the comment
Same for (01) so 4 does print just like 1.
Line (02) has an inline comment so the block comment starter is par of the comment and is ignored. Same for (04) and (10).
Line (03) is not in any comment and gets executed. Same goes for line (11).
Line (05) starts a block comment. Lines (06) and (07) are part of the block comment.
Line (08) stops the block comment.
but line 09 is NOT executed so it is still part of the commented out code....................
---------------------------------------------------------------------
February 11, 2009 at 3:31 pm
Charles Kincaid (2/11/2009)
Good point. But then
/*
Good comment not.
-/**/*/
does work. Does this remind you of the Perl parser?
That's not as bad as it seems when you break it out.
/*
Good comment not.
-
/*
*/
*/
I've never had the pleasure of working with the Perl parser. Does it defy logic?
February 11, 2009 at 4:38 pm
I wrote some stuff in Perl as that was what was available on the web server. It was not that bad to write code. You start with the inmost thing. Then surround with the next layer of processing. Then surround that with the next. Etc. Very powerful. I had very intense routines in a single line of code. Nice.
Now come back a couple of months later and need to make one little change. :w00t: Trying to uncoil those lines to remember what they did. It's not so easy to read what you wrote. :crazy:
Don't get me wrong here. Perl is fine. Many people use it and find it easy. I did not. It's the fault of me and not Perl.
ATBCharles Kincaid
February 12, 2009 at 3:33 am
Here's an interesting combination:
This code works perfectly OK ( the unmatched block comment marker causes no problems because it is part of an inline comment):
print '1'
--/*note unmatched block comment marker on this line, following an inline comment marker
print '2'
print '3'
result: 1 2 3
Now, suppose we are asked to disable the part of the code that prints 1 and 2 ... easy, we say 🙂 ... just put block comment markers around it ...
/*
print '1'
--/*note unmatched block comment marker on this line, following an inline comment marker
print '2'
*/
print '3'
result : Server: Msg 113, Level 15, State 1, Line 1
Missing end comment mark '*/'.
oops !
My attempt to explain the behaviour is: as soon as you are withiin a BLOCK COMMENT, the system ignores all INLINE COMMENT markers. For most statements, this doesn't matter, because the statement will not be executed anyway since it is part of the BLOCK COMMENT.
But START BLOCK COMMENT /* or END BLOCK COMMENT */ instructions which look as though they should be ignored because they follow a "--" , are actually processed, and may open a nested comment block or close the existing block or cause a syntax error.
Does that sound about right ?
Viewing 15 posts - 31 through 45 (of 53 total)
You must be logged in to reply to this topic. Login to reply