June 4, 2012 at 5:53 pm
In fact, your mindset is so much into that design approach that you put commas in the front of each line(card) just like we did in the 1960's.
That is interesting. I didn't know that was the coding style back in the 1960's. (That was a bit before my time. ;-))
I don't know what was in the Original Poster's mind, but I heard Adam Machanic recommend putting the commas for multi-line statements at the beginning of the line (as in the example) because it makes it easier to move the lines of code around. (Otherwise, you have to go back and clean up the commas if you need to swap lines in a CREATE TABLE or SELECT statement.)
Adam also recommended using the /* Blah, Blah, Blah */ comment syntax instead of -- for the same reason.
(Just a side note. :-))
June 4, 2012 at 7:21 pm
David Moutray (6/4/2012)
In fact, your mindset is so much into that design approach that you put commas in the front of each line(card) just like we did in the 1960's.
That is interesting. I didn't know that was the coding style back in the 1960's. (That was a bit before my time. ;-))
I don't know what was in the Original Poster's mind, but I heard Adam Machanic recommend putting the commas for multi-line statements at the beginning of the line (as in the example) because it makes it easier to move the lines of code around. (Otherwise, you have to go back and clean up the commas if you need to swap lines in a CREATE TABLE or SELECT statement.)
Adam also recommended using the /* Blah, Blah, Blah */ comment syntax instead of -- for the same reason.
(Just a side note. :-))
Actually, leading commas only help if you move or comment out the last line in the SELECT list. Likewise, trailing commas help only if you move or comment out the first line in the SELECT list. All of the lines in between don't matter which way you go.
If you truly want to make it easy to comment out or move liines, the commas should be on a totally separate line. Yeah... let's all adopt that standard.
That, notwithstanding, the real key is that if you write new code, be consistent. If you're modifying someone else's code, follow the "standard" already set in the code.
On the subject of using /*...*/ instead of double dashes... you should try troubleshooting code in black and white and see how much you'll like block comments instead of line comments especially if someone has the habit of just commenting out legacy code instead of deleting it. Who troubleshoots on a black and white screen anymore? Heh... when it does actually happen to you, you'll know. 😛
BTW, Joe is right. Leading commas isn't some new or even relatively new. Lot's of folks used leading commas on punched cards back in the '60s for the same reason. And, they ran into the very same problems I spoke of when they wanted to move or delete the first card in the list. When that happened, they became "cursers". 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
June 4, 2012 at 8:13 pm
David Moutray (6/4/2012)
I don't know what was in the Original Poster's mind, but I heard Adam Machanic recommend putting the commas for multi-line statements at the beginning of the line (as in the example) because it makes it easier to move the lines of code around. (Otherwise, you have to go back and clean up the commas if you need to swap lines in a CREATE TABLE or SELECT statement.)
Hi David,
You must have me confused with someone else. I abhor that style. I think it's twice as ugly to read; those of us used to the English language expect to see commas *after* each element in a list, not before. Perhaps it's different with other languages.
The usual argument I see for that style is that it makes it easier to comment out various items as needed. But I really don't see the benefit. It's a tradeoff. If you put the comma after each element, commenting out the final element requires a bit more work. Put the comma before, and now commenting out the first element requires a bit more work. It's a wash, so do what looks better. (After, every time!)
--
Adam Machanic
whoisactive
June 4, 2012 at 8:21 pm
You must have me confused with someone else.
Eh, my apologies. I was at a PASS convention. Whoever said it was incredibly handsome and had a smokin' hot babe hanging on his arm. Naturally, whatever he said had a lot of credibility! 😛
June 4, 2012 at 8:26 pm
David Moutray (6/4/2012)
You must have me confused with someone else.
Eh, my apologies. I was at a PASS convention. Whoever said it was incredibly handsome and had a smokin' hot babe hanging on his arm. Naturally, whatever he said had a lot of credibility! 😛
I'm pretty sure that was the AVN show, not PASS. And they were talking about colons, not commas.
--
Adam Machanic
whoisactive
June 4, 2012 at 8:28 pm
AVN? As in Aliens Vs. Ninjas?
June 5, 2012 at 8:32 am
Adam Machanic (6/4/2012)
David Moutray (6/4/2012)
I don't know what was in the Original Poster's mind, but I heard Adam Machanic recommend putting the commas for multi-line statements at the beginning of the line (as in the example) because it makes it easier to move the lines of code around. (Otherwise, you have to go back and clean up the commas if you need to swap lines in a CREATE TABLE or SELECT statement.)
Hi David,
You must have me confused with someone else. I abhor that style. I think it's twice as ugly to read; those of us used to the English language expect to see commas *after* each element in a list, not before. Perhaps it's different with other languages.
The usual argument I see for that style is that it makes it easier to comment out various items as needed. But I really don't see the benefit. It's a tradeoff. If you put the comma after each element, commenting out the final element requires a bit more work. Put the comma before, and now commenting out the first element requires a bit more work. It's a wash, so do what looks better. (After, every time!)
I respectfully disagree. It's not the same amount of work for two reasons.
1) The first field is often an ID field, and it is much less likely that you will want to comment out the ID field.
2) The end of the line isn't always the end of the line. If you put comments on the same line as your code and you are putting your commas at the end of the line, the comma needs to come before the comment. Trying to comment out commas that appear between code and comments on a line is much harder than commenting out commas that appear before both the code and the comments.
While T-SQL is based on English, it is most definitely not English. There is no reason that the same conventions that apply to written English need apply to T-SQL.
Drew
J. Drew Allen
Business Intelligence Analyst
Philadelphia, PA
June 5, 2012 at 8:41 am
drew.allen (6/5/2012)
I respectfully disagree. It's not the same amount of work for two reasons.1) The first field is often an ID field, and it is much less likely that you will want to comment out the ID field.
Maybe in your current project you like to put the "ID" first. Perhaps I like to put mine in the middle. Or write queries that don't have them at all. YMMV on that one, so it's probably best to avoid generalizations of this type.
2) The end of the line isn't always the end of the line. If you put comments on the same line as your code and you are putting your commas at the end of the line, the comma needs to come before the comment. Trying to comment out commas that appear between code and comments on a line is much harder than commenting out commas that appear before both the code and the comments.
Personally, when commenting a SELECT list, I'll generally put the comments just above the column I'm commenting. This is a typical commenting style used in a wide variety of languages, and helps avoid the need for horizontal scrolling, which you might have to do if your comment sits after the column expression and you have a lot to say. I think it's a much more readable, not to mention maintainable, way of doing things.
--
Adam Machanic
whoisactive
June 5, 2012 at 8:43 am
All kidding aside, I did once hear someone recommend that style. I am trying to remember where I heard or read that now. (If I recall correctly, I do believe I heard Adam recommend using block comments exclusively as opposed to inline comments.)
I must also that say I've gotten very used to putting commas at the beginning of the line. It works for me. I've had fellow developers become very annoyed at the way I convert inline comments to block comments, but I've not had anyone complain about putting commas at the beginning of the line.
To put everything in perspective, though, beyond a certain point, coding issues are a matter of personal taste. A given team should use a consistent style. Putting your commas at the end of the line (or the beginning) won't jeopardize the project, though.
The intense, religious arguments you can get into over coding style may jeopardize your health (or sanity) though! 😛
As Teddy Roosevelt said once (I believe), "Academic arguments are vicious precisely because they are over so little."
June 5, 2012 at 8:47 am
YMMV on that one
Oh, and I absolutely despise abbreviations! What, are you too lazy to type it out?
What the *&(^% does YMMV stand for?
(See what I mean about religious issues?) 😛
June 5, 2012 at 8:53 am
David Moutray (6/5/2012)
YMMV on that one
Oh, and I absolutely despise abbreviations! What, are you too lazy to type it out?
What the *&(^% does YMMV stand for?
(See what I mean about religious issues?) 😛
Really? Your Milage May Vary. When I see unrecognized acronyms, I tend to highlight it and do a search. Tells me pretty quick what it means.
June 5, 2012 at 8:57 am
David Moutray (6/5/2012)
(If I recall correctly, I do believe I heard Adam recommend using block comments exclusively as opposed to inline comments.)
Nope, that wasn't me either. I don't know why anyone would advocate one form of comment over the other, and to the exclusion of the other. Each comment form has its place. I tend to use inline comments when I want to leave a quick note, and block comments when I need to write more of a ... block ... of comments.
/***************************
This query doesn't do much,
but it will make for a nice
example, won't it?
***************************/
SELECT
--ColA
1 AS ColA,
--ColB
2 AS ColB,
--ColC
3 AS ColC
--
Adam Machanic
whoisactive
June 5, 2012 at 8:59 am
Oh, and you want to do that fifteen times per page while you're reading? What about corporate acronyms that don't exist on Google?
I know, I must have been a very uptight high school English teacher in a past life. Seriously, though, acronyms should be used sparingly, and they should be defined in every document in which they are used. Otherwise, they hinder communication.
I feel the same way about single-character database aliases or short variable names in code. It may be easier to type, but it is not easier to read. Code should be easy to read - for everybody.
That is JMO (Just My Opinion). 😛
June 5, 2012 at 9:01 am
Nope, that wasn't me either.
Dude, you are really making me look bad. OK, OK, I admit it was at a PASS party and I might have had a few (several) drinks.
I promise that I will stop taking your name in vain.
June 5, 2012 at 9:30 am
David Moutray (6/5/2012)
Oh, and you want to do that fifteen times per page while you're reading? What about corporate acronyms that don't exist on Google?I know, I must have been a very uptight high school English teacher in a past life. Seriously, though, acronyms should be used sparingly, and they should be defined in every document in which they are used. Otherwise, they hinder communication.
I feel the same way about single-character database aliases or short variable names in code. It may be easier to type, but it is not easier to read. Code should be easy to read - for everybody.
That is JMO (Just My Opinion). 😛
I do it when I don't know what it means. Sometimes I can figure it out by context. Some times I do have to ask. And, by the way, I don't like the use of acronyms exclusively. I get emails with articles that use acronyms exclusively and it bugs me, especially when 1) I have never heard it before, 2) it is the same as others I know but they don't make sense in this context (i.e. ASP - could mean Active Server pages or Application Service Provider).
I won't get upset at ihe use of acronyms that I can decern quickly from context, particularly on a site like this where most of them make sense to me.
And I do agree, the first time an acronym is used, especially on that may be confused or unknown, it should be defined.
Viewing 15 posts - 16 through 30 (of 40 total)
You must be logged in to reply to this topic. Login to reply