October 2, 2008 at 6:57 am
Hi Jeff,
No problem, let me your views when you've had a look.
Just on another point, ANSI 89 vs ANSI 92, do you know where I can find a quick summary of the benefits of ANSI 92 over 89?
Thanks
Jackal
October 2, 2008 at 8:22 am
"'dbo.selectthisandthat"
For my taste, I find this harder to read (mid-50 eyesight and all), it requires more attention to figure out the meaning of the name. I feel something is lost in readability - for humans.
I am sure there are other tricks to improve performance by making the code (a bit) less readable...
October 2, 2008 at 9:02 am
J (10/2/2008)
"'dbo.selectthisandthat"For my taste, I find this harder to read (mid-50 eyesight and all), it requires more attention to figure out the meaning of the name. I feel something is lost in readability - for humans.
I am sure there are other tricks to improve performance by making the code (a bit) less readable...
Don't think it's anything to do with age mate - IMO it's just a horrible crabby style of coding that deliberately ignores any consideration of legibility or the way people actually read. Right up there with everything on one line, no spaces after commas, no spaces after keywords and sundry other vileness leading to unreadable gibberish
October 2, 2008 at 9:09 am
"This way I can just tell the developer to run stored procedure 'dbo.selectthisandthat' and not have to worry about them calling 'dbo.SelectThisAndThat' and getting potential cache misses."
Would it be so much more difficult to order the developpers to use the exact name and casing as shown in the list of stored procedures ?
October 2, 2008 at 9:14 am
J (10/2/2008)
"This way I can just tell the developer to run stored procedure 'dbo.selectthisandthat' and not have to worry about them calling 'dbo.SelectThisAndThat' and getting potential cache misses."Would it be so much more difficult to order the developpers to use the exact name and casing as shown in the list of stored procedures ?
I understand your point J, and I agree with you 100%, but based off past experiences asking developers to doing something and them actually doing it are two very different things. I guess it depends the scenario and the extent of control you have over the database.
October 2, 2008 at 9:22 am
Jackall,
If "your" developers ignore your advice, you can bet there will always be one if not two who will decide that "selectthisandthat" is not legible enough and improve the casing.
No matter how much you try, you cannot "legislate" ego problems out of existence with casing style. And without seeing this as an ego problem, I would object to such casing. (It is an another matter if I would decide to ignore a DBA though. I just might develop my code with what I consider better casing and before releasing the code, use search and replace to restore the recommended casing).
October 2, 2008 at 9:29 am
Hi J,
I'm not saying that a dba's views would be ignored and I dont want to wonder off track. It's just in situations I have worked in, business requirements often come before the dba's requirements.
I have seen many a dba get angry because 'some code' has had to go in quickly to do this or that.
I agree with you 100% in your views though.
October 2, 2008 at 5:04 pm
You have found one of my little bug bears here. There is no excuse for producing badly formatted code. Just because code has to go in quickly does NOT mean a developer has to produce garbage code that cannot be read easily.
Any developer worth their weight should automatically produce code (be it for a production release or just simply writing a query to get some information) that is both readable and sensibly formatted without this taking any additional time.
Any developer that does not do this, is a lazy developer and a person I definately do not want on my team. A little harsh maybe, but I've had to re-format many a developers code just to see what the procedure is supposed to do.
A little time now can save a lot of time later.
-- John Oliver
Sometimes banging your head against a wall is the only solution.
October 2, 2008 at 7:26 pm
John Oliver (10/2/2008)
You have found one of my little bug bears here. There is no excuse for producing badly formatted code. Just because code has to go in quickly does NOT mean a developer has to produce garbage code that cannot be read easily.Any developer worth their weight should automatically produce code (be it for a production release or just simply writing a query to get some information) that is both readable and sensibly formatted without this taking any additional time.
Any developer that does not do this, is a lazy developer and a person I definately do not want on my team. A little harsh maybe, but I've had to re-format many a developers code just to see what the procedure is supposed to do.
A little time now can save a lot of time later.
Bloody well outstanding, John! I'm [font="Arial Black"]SO[/font] happy to finally meet someone who feels exactly the same way I do about this whole formatting thing and actually has the hair to say it out loud instead of me always being the one. 🙂
The big thing is in troubleshooting code. I've had to do exactly what you do ...
but I've had to re-format many a developers code just to see what the procedure is supposed to do
...a million times both at work and on these fine forums. I can almost always tell that code is going to be absolute crap for performance and/or resources just by looking at the format... if the developer (using the term loosely) doesn't give a rat's patooti about how it looks, they usually also don't care how well it works or not.
Add the requirements for proper embedded documentation that explains the "Why" of the code and you'll have found a kindred spirit in me. 😀
And, yes... I check for code readability and the use of common sense standards on interviews. If that offends someone, then they can simply go somewhere else to find a job. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
October 2, 2008 at 7:39 pm
Thankyou Jeff for the vote of confidence. It is good to know I also have a like minded person somewhere out there.
It is always troubling when you are at someones desk when they ask for help and you sit there and have to re-format their code.
Of course, the response you get is "Dont bother with that, I just need the thing to work" !!
GRRRrrrr.
And Jeff, I love my comments as I'm usually the poor sucker who has to re-visit my own code in 6 - 12 months time, and I'm always asking myself "Why did I do it that way?".
-- John Oliver
Sometimes banging your head against a wall is the only solution.
October 2, 2008 at 7:50 pm
Jackal (10/2/2008)
J (10/2/2008)
"This way I can just tell the developer to run stored procedure 'dbo.selectthisandthat' and not have to worry about them calling 'dbo.SelectThisAndThat' and getting potential cache misses."Would it be so much more difficult to order the developpers to use the exact name and casing as shown in the list of stored procedures ?
I understand your point J, and I agree with you 100%, but based off past experiences asking developers to doing something and them actually doing it are two very different things. I guess it depends the scenario and the extent of control you have over the database.
Heh... I fixed that in my previous shop... we instantiated standards and code reviews. That means that proper formatted, highly readable code became of part of their job and it figured strongly on merit increases and COL raises. You can bet dollars to Navy beans they turned to. 😉
My feeling is that the DBA has the final say so on what goes into the database... the standards we put in place gave the DBA the right to override any manager including the CIO and the CEO when it came to naming conventions, code functionality, code readability, code performance, and code scalability... schedules be damned! Of course, all that stuff was carefully laid out in the standards, the developers all had copies of it, and code review rejections for standards violations were kept track of.
As a result of all we did, change controls and the related post implementation sanity checks dropped from an average of 4 hours to just 15 minutes. Rework in the QA stage went from 70% down to less than 5%. The time to research lengthy/complicated code modifications went down from an average of 2 days to about 15-30 minutes. And the time difference for the developers to do it right instead of producing the unreadable crap they were previously writing was almost negligible.
When we first changed to the standards and started to enforce them, almost every developer got pissed off... some whiners even quit (thank goodness) because of it. As time wore on, they got used to it and developed some rather remarkable code that always ran first time (ie. very near zero defects). New developers that came in were told about the standards and the related expectations before they were hired. Quality of the the code went up, performance of the code when up, scalability of the code went up, deadlocks and blocking went down, and rework just about disappeared.
"Make it work, make it fast, make it pretty... and it aint done 'til it's pretty!" 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
October 2, 2008 at 7:55 pm
John Oliver (10/2/2008)
Thankyou Jeff for the vote of confidence. It is good to know I also have a like minded person somewhere out there.It is always troubling when you are at someones desk when they ask for help and you sit there and have to re-format their code.
Of course, the response you get is "Dont bother with that, I just need the thing to work" !!
GRRRrrrr.
And Jeff, I love my comments as I'm usually the poor sucker who has to re-visit my own code in 6 - 12 months time, and I'm always asking myself "Why did I do it that way?".
Agreed with all... I like your "tag line" on your posts, too, but my favorite would be "Sometimes banging the developer's head against a wall is the only solution." 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
October 2, 2008 at 8:14 pm
Jackal (10/2/2008)
Hi Jeff,No problem, let me your views when you've had a look.
Just on another point, ANSI 89 vs ANSI 92, do you know where I can find a quick summary of the benefits of ANSI 92 over 89?
Thanks
Jackal
Heh... I can tell you in the form of a couple of questions... What's the difference between a 4 function calculator and one with a square root key? If you're doing something complex, wouldn't you rather have a scientific or business calculator to use? 😀
I've found that, if you try to do anything really worthwhile in SQL, true code portability is pretty much a myth. Lots of folks will tell you that they try to write code as close to ANSI standards as they can and will actually go out of the way to do something in a more difficult manner to try to make code portable rather than using the extensions built into either SQL Server or Oracle or whatever SQL dialect they happen to be strapped with. That might be ok for low level GUI code, but when it comes to high performance, highly scalable batch code, I use ALL the tools available in whatever RDBMS I happen to be using.
For example... SQL Server doesn't have a CONNECT BY clause... would you give that baby up in Oracle just because a lot of RDBMS's don't have it and it might make your code non-portable? Hell no! Would you give up the power of UPDATE FROM in SQL Server just because Oracle doesn't have it. Hell no! Yeah, I know... MERGE is the way to go in Oracle... would you give it up just because it's not portable to most RDBMS's yet. Heeeelllll no!
Heh... that's my long winded version of saying, "No, sorry... I have no links that explain the differences between ANSI 89 and ANSI 92." :hehe:
--Jeff Moden
Change is inevitable... Change for the better is not.
October 2, 2008 at 8:20 pm
Jackal (10/2/2008)
Hi J,I'm not saying that a dba's views would be ignored and I dont want to wonder off track. It's just in situations I have worked in, business requirements often come before the dba's requirements.
I have seen many a dba get angry because 'some code' has had to go in quickly to do this or that.
I agree with you 100% in your views though.
Obviously, the DBA's didn't get angry enough. It doesn't take any more time to do it right and, if the DBA was doing his/her job, they'd simply refuse to promote the code. Of course, if they really wanted to do the job right, they'd have the nads to write a set of standards and get management's buy-in or find a job at a company that would.
DBA's that let crap code into the server just because someone wants it real bad, isn't really doing the job a DBA should be doing... protecting the server, the data, and the code. :hehe:
Remember, "If you want it real bad, that's the way you'll usually get it." 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
October 2, 2008 at 8:22 pm
Andrew Gothard (10/2/2008)
J (10/2/2008)
"'dbo.selectthisandthat"For my taste, I find this harder to read (mid-50 eyesight and all), it requires more attention to figure out the meaning of the name. I feel something is lost in readability - for humans.
I am sure there are other tricks to improve performance by making the code (a bit) less readable...
Don't think it's anything to do with age mate - IMO it's just a horrible crabby style of coding that deliberately ignores any consideration of legibility or the way people actually read. Right up there with everything on one line, no spaces after commas, no spaces after keywords and sundry other vileness leading to unreadable gibberish
Wow! Two more folks with the right idea! I love it! 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 31 through 45 (of 58 total)
You must be logged in to reply to this topic. Login to reply