March 5, 2008 at 6:08 pm
paulhunter (3/5/2008)
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?
I'm afraid I didn't understand the why of it. I've followed this thread from the beginning, and I don't remember anyone complaining.
March 5, 2008 at 7:58 pm
Could be my faulty memory. I thought I remembered a post that went to the effect of "why are you wasting your time on this". If I was incorrect then I apologize.
--Paul Hunter
March 6, 2008 at 4:10 am
Ok, you guys... be nice...
--Jeff Moden
March 6, 2008 at 4:24 am
Jeff,
Good to hear from you again. As you requested, I attached a copy of the spec I follow. It took me a while to find it. Had to rebuild my laptop with XP (Vista issues) and couldn't find my jump drive.
-- Paul
--Paul Hunter
March 6, 2008 at 5:07 am
Nicely done... there are a couple of things I do exactly the opposite of you, but if I were working in your shop, the rules you wrote are pretty easy to follow. And, that's the key...
--Jeff Moden
March 6, 2008 at 6:31 am
paulhunter (3/5/2008)
Could be my faulty memory. I thought I remembered a post that went to the effect of "why are you wasting your time on this". If I was incorrect then I apologize.
Now that you mention it, I sort of remember seeing that somewhere.
Regarding you standards document. Funny thing. The code sections showed a font named 'Letter Gothic MT'. My machine with Office 2k7 displayed it as a 3 of 9 barcode (readable). I haven't a clue why, but I'm assuming I'm the only one this happens to.
March 6, 2008 at 6:43 am
Tom Garth
Regarding you standards document. Funny thing. The code sections showed a font named 'Letter Gothic MT'. My machine with Office 2k7 displayed it as a 3 of 9 barcode (readable). I haven't a clue why, but I'm assuming I'm the only one this happens to.
Weird things happen with fonts. A lot of folks have had a recurring problem on the NTSSUG.org listserv with some strange characters their posts. In the document, there should be a named style (code block I think) that you could change to the font of your choice.
--Paul Hunter
March 6, 2008 at 6:59 am
Hi,
Interesting topic 🙂
Does anyone else think it's slightly obtuse to spend time creating naming standards for tables and then alias them in code with something so meaning less as a forcing anyone without an encyclopedic knowledge of the system you've written for to hunt the alias :unsure: I appreciate it may be quicker to write code this way but I’ve never felt that time spent typing was of paramount importance compared to time spent thinking about what to type or trying to understand what someone else typed long after they're dead. C’est la Vie.
K.
March 6, 2008 at 10:36 am
Karma (3/6/2008)
Hi,Interesting topic 🙂
Does anyone else think it's slightly obtuse to spend time creating naming standards for tables and then alias them in code with something so meaning less as a forcing anyone without an encyclopedic knowledge of the system you've written for to hunt the alias :unsure: I appreciate it may be quicker to write code this way but I’ve never felt that time spent typing was of paramount importance compared to time spent thinking about what to type or trying to understand what someone else typed long after they're dead. C’est la Vie.
K.
Normally an alias will be one of two thing. I prefer a simple mnemonic for example Customer would be c, CustomerOrder would be co, etc. Others prefer aliasing the tables starting at A and working their way thru the alphabet. Both are valid as they decrease the length of information used to access the data column.
Assume you have a table named CustomerTransactionHistory (which I do) which is owned by the Accounting schema (which it is). So to access any column you will need to type Accounting.CustomerTransactionHistory.SomeColumnName. Oh joy, I'd love to type that 60 or so times. If I alias the table (cth using my method), I have cth.SomeColumnName. I could avoid aliasing and hope nobody adds a column with the same name to another table listed in the join. Then I wind up at some later time with an "ambiguous column" error. Those are always fun to track down.
So, you can type a lot, type a little or produce code that's easy to break. C’est la Vie.
-- Paul
--Paul Hunter
March 6, 2008 at 10:45 am
Karma (3/6/2008)
Hi,Interesting topic 🙂
Does anyone else think it's slightly obtuse to spend time creating naming standards for tables and then alias them in code with something so meaning less as a forcing anyone without an encyclopedic knowledge of the system you've written for to hunt the alias :unsure: I appreciate it may be quicker to write code this way but I’ve never felt that time spent typing was of paramount importance compared to time spent thinking about what to type or trying to understand what someone else typed long after they're dead. C’est la Vie.
K.
If the code is nicely formatted, anyone coming along can easily determine the reference for an alias without having an encyclopedic , or any other kind of knowledge about the system.
That's one of the reasons we've been having this discussion.:)
March 7, 2008 at 2:17 am
Tom Garth (3/6/2008)
Karma (3/6/2008)
Hi,Interesting topic 🙂
Does anyone else think it's slightly obtuse to spend time creating naming standards for tables and then alias them in code with something so meaning less as a forcing anyone without an encyclopedic knowledge of the system you've written for to hunt the alias :unsure: I appreciate it may be quicker to write code this way but I’ve never felt that time spent typing was of paramount importance compared to time spent thinking about what to type or trying to understand what someone else typed long after they're dead. C’est la Vie.
K.
If the code is nicely formatted, anyone coming along can easily determine the reference for an alias without having an encyclopedic , or any other kind of knowledge about the system.
That's one of the reasons we've been having this discussion.:)
It's a fair point if you are lucky enough to have such standards in place before you have to pick up someone's work later on.
🙂
March 10, 2008 at 2:59 am
I dunno 'bout you Pete but I normally put a connection to my database in my code (VB etc.) so the program will know where to look for the stored procedure. I need to tell you guys that my mentor and boss (who's been programming since we were just twinkles in our fathers' eyes) knows what he does and I am sure he would have taken that into consideration.
In order to make it easier for someone else to your database layout as well as your SQL code layout needs to be 100%. I also need to remind you guys that there are people out there that will do there darndest to steal your product and will then need to be able to read your database. WHAT NOW???!!!:w00t::w00t::w00t:
:-PManie Verster
Developer
Johannesburg
South Africa
I can do all things through Christ who strengthens me. - Holy Bible
I am a man of fixed and unbending principles, the first of which is to be flexible at all times. - Everett Mckinley Dirkson (Well, I am trying. - Manie Verster)
March 10, 2008 at 4:15 am
dean gross (3/4/2008)
Andrew Novick's Transact SQL User Defined Function's book has an excellent discussion on Documenation, Formmatting and Naming Conventions in Chapter 6. In this, some of his reasons for the comma, or separator first formatting approach are:makes it easier to add comments to the end of the line
makes it easy to comment out a line
give visual prominence to the separators
Dean
Both styles are easy to add end line comments to so that doesn't matter. Both are easy to comment out a line except one is hard to comment out last line and one is hard to comment out first line so that doesn't matter. And personally, I'd rather have bisual prominence on the names of things 'cause I know the separators are at the end so that doesn't matter either. Further, SQL is an English-like programming language and I wouldn't expect commas at the beginning of a line in a book so why would I expect them in SQL?
So what are the advantages of commas first? Zip... nada... none... zero... it's totally a matter of personal preference.
--Jeff Moden
March 10, 2008 at 6:36 am
Jeff Moden (3/4/2008)
No, no! Copy the code and paste it into MS Word... do a Search and Replace...Search for ^l (circumflex small-"L") and replace it with ^p (circumflex small-"P"). Then copy from there and paste into QA... formatting will be preserved.
I've just got round to trying this, and I found that simply pasting into Word and then copying again and pasting into QA did the trick. 🙂
I'm using Office 2003 sp2 FWIW...
Edit: Ignore the above, They have fixed it! Now you can paste directly into QA! Woo-hoo! 😛
Further Edit: I went to see if they announced this and saw Jeff posted something similar on Friday!
Dave J
March 10, 2008 at 11:59 am
paulhunter (3/5/2008)
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
On the "live and let live", no. Not at all. I do like to have some standard and have it be held to strongly. My point was that style becomes less important when compared to really, really horrible code; no amount of layout standards is going to make a badly written query perform well. I currently have to prioritize performance over style. Once I've got all the broken stuff fixed, I'll definitely go back and re-layout all the code to fit a standard.
On the point of standards being important in communication: Yes! Absolutely! I'm the person who keeps beating on coders who follow stringent standards in their code, but who refuse to follow standards when they try to write comprehensible English. Standards are all about communication and are necessary in all forms of communication. Heck, languages are just standards for sounds and symbols, when it really comes down to it.
- 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
Viewing 15 posts - 76 through 90 (of 90 total)
You must be logged in to reply to this topic. Login to reply