March 4, 2008 at 10:54 am
Right you are, Jeff.
I haven't heard an argument yet that would convince me to give up the much more aesthetically pleasing comma last scripting.:cool:
March 4, 2008 at 12:02 pm
Jeff Moden
SQL is supposed to be an "english like language"... in English, we don't start new lines with a comma. I guess I can understand why some people might like it... I just don't allow it in my shop because more people seem comfortable with the commas at the end of the line...
So, by this logic every line begins a new sentence in english. SSQL is like a language in that they begin with a predicate (select, insert, update, delete) and end with conditional. So you select a list of values from a table and we're on the same page. Question, do you place every word of a sentence on a new line? I guess not as thats not how you've posted. This is where coding is different from a language. You will do things differently depending on the context. In the case of code, a comma separates a list of values (columns) by placing the comma at the beginning I can easily comment out lines (columns) 4-8 and 12, 15, 25 and 27 of a long operation with minimal fuss. If the comma is at the end then I have to start at the end of line 3-8, 11-13, 14-15, 24-25 and 26-27. I have to use a block comment instead of an inline comment. Plus the inline comment easier to remove. ctrl+shift+r.
--Paul Hunter
March 4, 2008 at 12:16 pm
paulhunter (3/4/2008)
Jeff Moden
SQL is supposed to be an "english like language"... in English, we don't start new lines with a comma. I guess I can understand why some people might like it... I just don't allow it in my shop because more people seem comfortable with the commas at the end of the line...So, by this logic every line begins a new sentence in english. SSQL is like a language in that they begin with a predicate (select, insert, update, delete) and end with conditional. So you select a list of values from a table and we're on the same page. Question, do you place every word of a sentence on a new line? I guess not as thats not how you've posted. This is where coding is different from a language. You will do things differently depending on the context. In the case of code, a comma separates a list of values (columns) by placing the comma at the beginning I can easily comment out lines (columns) 4-8 and 12, 15, 25 and 27 of a long operation with minimal fuss. If the comma is at the end then I have to start at the end of line 3-8, 11-13, 14-15, 24-25 and 26-27. I have to use a block comment instead of an inline comment. Plus the inline comment easier to remove. ctrl+shift+r.
Actually - no you don't. It's no harder to comment or un-comment with comma first or last. It's also no harder to add comments (that argument really doesn't seem to wash for me). You're just not commenting out the SAME commas. It's a visual thing - really - it works the same. It's painful only when you're grabbing "one of the end" columns (first or last).
And the comment add/remove commands are now standard with that of VS2005 (CTRL-KC and CTRL-KU).
To me it's a visual thing - no more, no less. Having the comma at the end tells me that I'm still in the "value list" (as you described) part, and not moving on to another clause. That's a value to me. That being said - I'm sure that if I were to stare at comma-first code for six or seven months at a time - it would make some sense to me.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
March 4, 2008 at 1:10 pm
paulhunter (3/4/2008)
So, by this logic every line begins a new sentence in english.
Heh... don't be warping my words, Paul... I said a new line never starts with a comma...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 4, 2008 at 1:56 pm
Jeff, you're so right on so much if only you'd come the the bright side and embrace comma beginnings. Like it you would, hmm.
--Paul Hunter
March 4, 2008 at 3:29 pm
Heh... no,... I'll happily continue to be "wrong" on this one... 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
March 5, 2008 at 6:45 am
SSW has recommendations posted at http://www.ssw.com.au/ssw/Standards/DeveloperSQLServer/SQLServerStandard_3_StoredProcedureFormatting.aspx . They also have lots of guidelines on other topics associated with programming
March 5, 2008 at 6:48 am
XML and HTML have standard formatting conventions, and when I use tools to write this type of code the tools have a menu option to apply the standards and fix the formatting to line up all of the indents, provide consitent grouping etc. How come SQL Server does not have similar functionality? SQL has been around longer than HTML and XML, but does not seem to have similar Standards as these. Any ideas why not?
Dean
March 5, 2008 at 10:17 am
dean gross (3/5/2008)
XML and HTML have standard formatting conventions, and when I use tools to write this type of code the tools have a menu option to apply the standards and fix the formatting to line up all of the indents, provide consistent grouping etc. How come SQL Server does not have similar functionality? SQL has been around longer than HTML and XML, but does not seem to have similar Standards as these. Any ideas why not?
Dean,
Not intending to be flippant, but have you been reading this thread? Two people (me and Jeff Moden) that agree on large chunks of the style such as, naming, indenting, the need to have the standard posted for developers, we can't agree on where to put the comma (if only he'd see the light and do it my way 😉 ). Add in all the flavors of SQL, (ANSI 89 syntax, ANSI 92 syntax, Oracle, SQL Server, Sybase, etc.) and I surprised that we even agree on the select keyword.
Microsoft could offer what you ask but that then opens them to having to support 30,000 different variations. It gets them into an area that is more a matter of preference rather than substance. I believe you will see from this post that most people agree that there should be a standard that is followed and published but that each standard is and should be different so that it supports their company goal. That goal should be all of our mantra: neat, consistent, well commented code is understandable code, understandable code is debuggable and supportable code.
--Paul Hunter
March 5, 2008 at 10:51 am
dean gross (3/5/2008)
SSW has recommendations posted at http://www.ssw.com.au/ssw/Standards/DeveloperSQLServer/SQLServerStandard_3_StoredProcedureFormatting.aspx . They also have lots of guidelines on other topics associated with programming
...and hopefully, nobody reads the post at that link, or this thread will continue on for another week discussing/arguing parameter/variable naming conventions and standardizations.:w00t:
March 5, 2008 at 11:06 am
Heh... even worse... all we really need now is for Joe Celko to jump in with his ISO standard mantra... 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
March 5, 2008 at 11:42 am
paulhunter (3/4/2008)[hrThe only place I've found even a small issue is if it's the first column. Then the first style is easier. I rarely have only one column so, all things being equal, I'll live with the better approach of the second style and just deal with the "first column pain".
So, what you're saying is that "first column pain" is less than "last column pain"? Because all the columns in between are handled exactly the same in either case.
I fail to see an advantage to either method over the other. Use whatever you're comfortable with, but don't try to push the idea that it is somehow inherently superior.
Personally, I don't like vertical lists of columns and prefer a paragraph format for them. It's just easier for me to read. If I worked in a shop where someone else set the rules on format, and they wanted a vertical format, I'd use it. But I find it less readable. (I've been reading left-to-right since I was four years old. I don't read top-to-bottom as easily. And for the argument about a column name being easier to find in one or the other, I don't buy that Ctrl+F has a preference for one layout over the other.)
My main reason for this is that I find:
insert into dbo.Table1 (
col1, col2, col3, col4, col5, col6)
select
col1, col2, col3, col4, col5, col6
from dbo.Table2
easier to read and debug than:
insert into dbo.Table1 (
col1,
col2,
col3,
col4,
col5,
col6)
select
col1,
col2,
col3,
col4,
col5,
col6
from dbo.Table2
Because the columns can be made to line up with each other, I find it easier to identify what's going on with it. "The select statement has more columns than the insert statement" type errors become easier to debug for me in the first layout. It's even more pronounced if it's more than a few columns, like 30+ in some tables. I don't like having to scroll up and down repeatedly, or print the code out and match the columns up with a pen.
At the same time, I don't find the vertical layout that much harder to read, so it doesn't matter that much to me. It's just not as easy.
My pet peeves with layout are lines that go too far to the right, so that I have to scroll horizontally to read them, and layouts with multiple lines of whitespace between elements of the same command. Beyond those, I spend enough time fixing code that's so bad that the layout really, really, really doesn't matter.
The layout of:
Select ...
From ...
Where coalesce(convert(varchar(25), datecolumn1, 101), convert(varchar(25), datecolumn2, 101), convert(varchar(25), datecolumn3, 101)) = coalesce(convert(varchar(25), @date, 101), convert(varchar(25), datecolumn1, 101), convert(varchar(25), datecolumn2, 101), convert(varchar(25), datecolumn3, 101))
really doesn't matter to me in the slightest. ALL CAPS keywords, all lower keywords, whitespace, indentation, position of commas, etc., all become trivial when faced daily with stuff like this.
I could even live with no layout standards at all, if the code were a little less ... well ... whatever that code is.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
March 5, 2008 at 4:58 pm
GSquared
So, what you're saying is that "first column pain" is less than "last column pain"? Because all the columns in between are handled exactly the same in either case.
I guess in my own twisted little way, that is exactly what I'm saying. I'm glad you have a "live and let live" attitude about coding. More power to you. I've consulted at a number of companies that had that attitude as well. Most ended up in the same situation Jeff Moden described earlier in this thread. There would be a 2-day turn around and multiple breaks just to change a line or two in a procedure because of bad code that was laid out poorly and difficult to understand.
Most coding errors pop out when the stuff is easy to read and understand. Logic errors are always harder to find. I'll grant that the side-by-side stuff is more compact. But I did notice you had line breaks after the update and select statements and that's just "style" provided for your readability. the database engine doesn't need any line breaks, indenting or even unnecessary spaces so, why not just place all code on a single line? The answer, as I'm sure you would agree, is that it improves the "readability".
You also mentioned that you didn't see any advantage to the line/column format. On that score it's a matter of taste. If you script your code out to files and then use version control, red-gate or any of the visual diff tools then the changes just pop out.
Remember, standards are like religion to many people. In my opinion they are an indispensable means for facilitating communication between developers. I'm passionate about this subject because I've seen hurdles fall, quality improve and clients be very happy when a group of developers got on the same page about the standards they would follow.
[opinion]
One final note, and it applies to all reading this or any thread. It seems strange to me that you would read the subject and then post to that thread that you don't like the subject. OK, then move on to one that does interest you.
[/opinion]
--Paul
--Paul Hunter
March 5, 2008 at 5:07 pm
[opinion]
One final note, and it applies to all reading this or any thread. It seems strange to me that you would read the subject and then post to that thread that you don't like the subject. OK, then move on to one that does interest you.
[/opinion]
--Paul
Huh?
March 5, 2008 at 5:20 pm
xmlish short hand for stating it's an opinion. Or, was the "huh?" that you didn't understand the why and where of that comment?
--Paul Hunter
Viewing 15 posts - 61 through 75 (of 90 total)
You must be logged in to reply to this topic. Login to reply