Develop a standard header for stored procedures, views and user-defined functions. Include details such as a brief description of the object, specification document, author, date created, change history, etc.Throughout the application, develop and maintain a uniform style of commenting. This improves the readability of the code and represents a professional approach.
The bottom line message in this article is "Comment your code if it's not absolutely clear what you are doing".
I like that. It's what I do. It's what I want my developers to do.
It would be nice to have more elaborate examples.
Sample code commenting style would make a great little web site.
At my current place of employment, over 6 years and 20 developers, there have only been 2 that comment with any regularity.
The first one, who has long since moved on, simply put his name and a creation date in the sproc. But at least I could then go back to him if I had a question.
The other one is me.
Regards,
Scott
I've been at my current job for 5+ years and it seems like no one in our development dept ever provides comments in any type of code be it in the program code (we are a software company) or in DB objects such as SP's, UDF's, Triggers, ect. We also have a proprietary scripting that allows our clients to create txt files that contain all teh information needed to create custom reports that can be excuted within our program. We provide a large number of stock versions of these for clients to use. We like the whole scripted report concept much better then reports that are hard coded into the program because it's much easier to update and maintain them. The porblem is there are often no comments in those iether and so clients and those of us in support (where I work) have no idea how many are suppose to work. I have voiced considerbale concern over this to no avail. What finally did me in on this and made me give up was when I asked a senior VP about this one day. I said that while doing so for existing DB objects may be to much to ask, can we at least put in a rule that from this point forward any items added to the schema can not be included in the final product that goes to the client until the developer has added comments to our DDF (Data Dictionary File similiar to an ERD). His response was no and that asking them to do that was asking too much. They had more important things to do then worry about documenting everything they do.
Can anyone share a personal experience that tops that?
Will
