"Here is the IDesign C# Coding Standard for development guidelines and best practices."

[Mark Brown]

This is written by Juval Lowy, which is a sort of hero of mine. A first look shows some really deep and thoughtful standards in there. I'm thinking that every company should have coding standards, and these are a good start. What do I mean by "start"? I mean that most companies will probably find at least some of the stuff in there redundant for their coding tasks, so you'll need to create a skeleton of what you would actually use in your own company.

When I helped implement coding standards at on eof my previous jobs, I learned some good lessons:

• Make sure all the employees agree with the standards. I'm not saying that they should all like it, because language wars are always there, but they should all agree to practice them to the letter.
• Consult with everyone about the document. Make a meeting, go through the standards one by one, and change /add/remove whatever you like. But make sure everyone understands that once it's final, its final.
• No need to go overboard. Some things are better left alone. Also, no one will bother adhering to a 250 page document.
• For the first few weeks after starting, follow the standards ,and all the team's code with 12 eyes. Sometimes people need to be reminded to do this and that, it's human.
• The one who "drives" the standards should know them all by heart. No way can they be asked a question about the subject and not be able to answer quickly.
• Every standard should come with examples of "bad" code and "good" code.
• Have a first page in the document that states the  "reason for doing this" . Programmers are human. Humans usually resist change. Programmers are also logical. If you explain why, they will understand and agree.
• Try to explain the reason behind the most important standards separately. things such as "why is it best to write comments this way and not that way" are usually good because people tend to remember and do what they think is logical. If they don't know why they are doing it this way, they won't remember to do it the right way next time. If they *do* understand, doing it in another way will just seem "wrong" to them , which is what you are looking for.
• Some people will resist change no matter what. Deal with it. Make them adhere. there are no two ways about it. "Broken window theory".
• If you have old code that is nowhere near what the standards look like, refactor it with time. If some peace of that code needs to be worked on, make it adhere to the guidelines as much as possible. People need to learn to take responsibility of every piece of code they lay their hands on. Refactoring is a way of life, not a task.
• Have a standard for C# and VB.Net and any other language you use ready in advance. The parts that overlap go in an overall document, and the others go in separate documents.