question

I would recommend building your own. Aside from certain absolute basics, most coding standards are a matter of taste. I prefer camelCase, but I know some who prefer using underscores, and as far as I know there is no objective difference in that or most other matters of coding standards. As for basics, some things I would include in any coding standards document include: - Validate all user input, especially if it will be passed along to another entity such as SQL Server. - Comment in the code extensively. When in doubt, overcomment rather than risk undercommenting - All variable names must be meaningful - All code must be checked into source control (I would specify the details, but the details are organization dependant) - All code must go through review before production. I will also point out that while I consider those all basics that should be in just about any coding stnadards document, I have deliberately and knowingly broken all of them at one time or another. I have skipped validating if I knew that there set of users would be both limited and trained. I have used one letter variables when in a hurry or if I just couldn't think of a meaningful name. I am normally devouted to source control, but oddly enough I have been in situations where it was not an option. And I have been in projects where there could be no formal review because the development team for the entire organization was me. Now, some other things you may want to include, but that are highly based on taste and needs of the organization are: - Standards for object name formatting - A standardized file header providing basic information - Documentation outside of the code itself (I generally limit this to the end user manual only. I prefer all technical documentation to be inside the code itself, it makes it more likely to be both read and updated. But this varies alot on the details. I tend to work in very small teams of no more than 5. Truly large teams might find outside documentation to be a necessity. - Details on how to use the organizations source control system. Most are simple and straightforward, but large projects may involve multiple branches as old versions get patches separate from the trunk of the new version, etc - Details on the testing regime required (unit tests are fantastic, but not always appropriate depending on the type of code, etc)

I agree with Timothy. One thing I would highlight that he said is testing. Often new code is tested on QA server without a load. When it goes to production the code performance is poor. I find many developers just write the SQL good enough to get the results they want without any consideration of concurrent load or the execution plan itself.