Coding guidelines are important, but be careful not to:
- be too pedantic. Easy to follow/easy to remember rules are good. Public (eg: to your customers) interface standards are good. Imposing if an internal variable must be called num_of_elements or number_of_elements or nelem is too much.
- stepping from standardization into their creativity. For example, deciding that Singletons are forbidden is too much. Being a programmer is not more different than being an artist. You have to leave some degree of creativity.
In addition:
- Do peer review. When a developer commits some code, another developer must review it and approve it, also in terms of coding standards. If a fault is found, you don't put blame on a single person, which is never good, but you split the chance of the error to happen to be simultaneously on two (willing or unwilling) developers.
- If you are a manager, do find the time to perform this review as well, even code with them. A good manager is part of the team, and shares its tasks and its burden. If you are just a "mail, documents and orders" kind of manager, you will not get respect from your team, in particular if made of enthusiasts, as opposed to mindless typing monkeys. Be as you are a more experienced team member, get your hands dirty together with them.
