Coding Guidelines and Beautiful Code

For a team meeting I was asked to supply one slide's worth of C# coding guidelines.  Here are the talking points I came up with:

Follow “Design Guidelines for Developing Class Libraries” on MSDN.
Naming:   PascalCasing/camelCasing, IMyInterface, avoid abbrv, appropriate namespaces.
Order of declaration: Internal members, properties, ctor, methods, indexers.
Documentation: Use XML documentation for public.  Why & how, not what.
Validation: Assume user input is invalid, external calls will fail.  Do the right thing on failure (see Exception standards).
Globalization: hardcoded strings, dates, currencies, use of ToString().
Extensibility and Reuse: Provide appropriate events.  Build at the “right” level of generality.
Write beautiful code:

• Code should compile without warnings.
• Avoid really long methods.
• Think about naming.
• If you are copy/pasting, you are doing something wrong.

The whole notion of coding guidelines is interesting, particularly in the context of a team.  If you write down all the things that you should and should not do when writing C# code, you get an extremely long list.  On our team all code is reviewed before check in, and we expect that we'll hold each other accountable for following the guidelines. However checking for all the guidelines, even with the help of FxCop, is difficult.  So I wanted to focus on a couple of key areas.

One last thing - I believe in beautiful code, but the standard is not absolute.  Beautiful Fortran looks different from beautiful C#, just as a word-by-word translation of a great Russian novel into English will look awkward.  The language is the medium, and an artist deeply understands the characteristics of the medium in order to bring about the result he or she is looking for.