Are you adding decent comments to your views, stored procedures and scripts?
I fluctuate between having no comments at all or using a full comment such as...
/***********************************************************************************
**
** Server: SQLL032P
** Database: iPR
**
** Script Name: 0001_Split_Relevant_References_By_XML_Name_Value.sql
** Description: Script splits out the node names and values of the data filtered
** by the variables listed in line 54 onwards.
**
** Author: Ian Roke
** Created: 15/11/2008
** Modified: 21/11/2008
**
** Notes: Creates two temporary tables.
** - ##SelectData
** - ##SplitXML
** Uses a cursor to loop through data and split XML.
**
** Inputs: Filters to show relevant detail. (Line 54)
**
** Outputs: XML BLOB split down into name/value stored in ##SplitXML table.
** Data only available in scope of script.
**
***********************************************************************************/
What do you guys do?
I want to know is there any standards suggested by Microsoft in T-SQL coding?? Please share me if you have any links..
AFAIK there are no set standards which makes my job even harder.
Best Answer
I do, and I try to get the other developers to do too. Not quite as formal as the example you posted but at least to put a block in to say what the procedure is attempting to do, what it supports (application, reporting services, etc), who wrote it and when. If there is also a change history with Date, By and Description then I count myself very lucky. I also try to add useful comments in the script.
It doesnt always happen and there isnt any standard we work to but it is certainly easier when you come back to a script 6 months after deployment and the comments get you up to speed more quickly. Its also good if you are trouble shooting an issue and see a recent change mentioned. If backing out the change fixes the issue then the developer gets the code back to resolve and re-deploy
Different people see things differently, but I am a fan of literate programming. When in doubt, comment it. If you think you have too many comments, you may almost have enough. Remember, there is a good chance someone else is going to have to maintain/update your code later, help them understand it. Even if you know you will be the only editor, there is a good chance you forget things 6 months later.
Tsk tsk. Honestly... sooner or later you need to learn that there are circumstances where it is BRILLIANT entertainment to eschew such things as:
- Meaningful commenting (trust me, you're better off commenting only insofar as it involves commenting out vast blocks of unneeded SQL, but never say why).
- Sensible attribution (if you've copied someone's code and it's better than what you could write, pass it off as your own).
- Meaningful object names (instead go for col2, col2a, Col-2b, COL_3)
...and so on.
Consider the following situtation. You decide to set something up from scratch. You're not formally qualified to do database work, but your boss is not "techo" either and doesn't get the significance of the deficiency. And it looks like fun. All those neato green ticks and progress bars whirring away in the installer. Databases are so cool! So you convince your boss you can save him or her $80,000 over the next three years if you have a stab at it yourself. You take the plunge and make a bit of a pig's breakfast of things. Because you're only accountable to the IT equivalent of tepid custard, you can drag this situation on for years. "It runs slow because we have slow hardware." "The problem's not the database, it's the user." "It's a very complex question..." Then one day... you get promoted (oh yes you do, cos you're the hero who set up "the system"). Now you can start to cash in and have some real fun. This is when you recruit some poor feckless sap into your old position; he or she will be COMPLETELY at your mercy. Because there's no doco, no orientation, no handover, they will have a choice between:
1. Spending days forensically picking through your spaghetti, to get even the most mundane and basic tasks done. Remember they will work hours of unpaid overtime early on just to make a good impression.
2. Grovelling to you to show them what your code is supposed to do. Now you get to roll your eyes and look with annoyance at your watch. Give them a few snippets of code that look related to the problem at hand, but in fact are not.
Ultimately they'll lurch back and forth hopelessly between both options and you'll be able to ride in on your white horse and save the day endlessly, all the while winking at YOUR boss and explaining in that oh so avuncular way, that "the newbie is taking a while to settle in, but I'll sort him/her out."
With any luck you could get yourself a payrise as well as the promotion. "We had no idea you were so indispensable Smith, until we saw that prize fool that came in after you. And he/she came with such good references too..."
+1 GPO. Very droll. Next (serious) question should be "What's the best way to deal with substandard work you've inherited?" Apart from giving people a good laugh, there's not much value in badmouthing the previous incumbent because 1. You don't know the pressure they may have been under to put code into production. We've all delivered stuff we weren't totally happy with. 2. We all learn (hopefully). Ever gone back and looked at code you wrote six years ago? The chances that you have not learned better ways to do things should be remote. 3. They may be perceived as a valued member of the organization, in spite of the mess they left you. 4. Whining won't fix anything. All I can suggest is "Keep plugging away and try not to stoop to the levels you've inherited."
