We've all done it. You're tired of the one colleague who always codes with a layout that you can't stand, so a coding standard is brought up. Before you do so, consider this advice:

You see code like:

if (a > b) {

clashing with the person who insists that the opening brace should be on a new line, and the new guy who doesn't even put a brace around a one-line if, just writes it all on one line:

if (a >b) CallC();

So you decide to put a common standard in place. Here are my thoughts on doing that:

• Buy before you build. There are several standards out there, and a lot of thought has already gone into them. It may pay to pick one off the shelf. If none fits exactly, base your standard off the closest and just note the changes and additions. Make it easy to add to, have a wiki.

• An automated standard is better - see StyleCop and StyleCop for Resharper, and FxCop/Code Analysis

• Never say Never. Very few things have to be an absolute rule. Many rules are better off as "should" not "must", or phrased as "prefer x to y in order that z" to allow human judgement.

• Have reasons. Give reasons for your decisions. Rules without reasons behind them will eventually outlive the reasons and be kept as ossified dead weight. Give context and pros and cons so that people can make informed decisions on if the rule applies or not. There may not always be such a thing as "best practices", but there are good practices in context.

•De gustibus non est disputandum. Regarding contentious matter such as indentation and layout, "It looks better that way" is not a reason; it is just force of habit and taste. Try to remember that when your tastes clash with other people's tastes. Source code formatting is legendary for launching as many pointless arguments as "vi vs. emacs"

The only book that I have seen that tries to find solid reasons for preferring one layout to another is of course Code Complete.

• The more widely adopted the standard already is, the better. A teamwide standard is better than an individual one, company-wide is better still, industry-wide is best. You won't get your exact preference - a common standard is a compromise, even if it's just common among two people. You'll get used to the standard surprisingly quickly. Try a different standard once in a while to see how you feel about it after using it.

• Go beyond indentation and naming into higher level topics. Start with the basics, but that stuff is cut-and-dried and automatable. Once people get the hang of that, it frees thier minds up to think about less mechancial things, those little architectural decisions that make up day-to-day programming. Provide further reading and for those pressed for time (and we're all pressed for time), links to short articles on SOLID principles, etc.