After spending some time resolving a number of code analysis warnings, here's a massively incomplete list of small things to do to help you produce better code.

At the project level:

• Turn on "Treat Warnings as Errors" on your projects. This can be a very big thing indeed if you do it in a project with lots of errors, so do it early. I've discussed this previously.
• Turn on code analysis and have code analysis errors treated as errors. Be aware that there are legitimate cases where warnings should be suppressed.
• Turn off code analysis rule CA1020: Avoid namespaces with few types. I understand the intent behind the rule but in practice it's just not helpful.

In code:

• Supply CultureInfo and IFormatProvider instances as appropriate to methods like String.Format, Int32.Parse and the like. There exist helpful code analysis rules to detect when you fail to do this.
• Implement the standard dispose pattern on anything that holds an IDisposable resource or unmanaged resource.
• Validate your arguments.
• Throw a more specific type than Exception. This gives more context about the nature of the problem.
• Don't just create your own exception class and throw that everywhere. That's not really adding anything. Custom exception classes for specific scenarios can be helpful but check if there's a relevant framework exception that would be suitable (or that your custom exception could derive from).
• When rethrowing an exception use throw; rather than throw ex; to ensure that the stack trace is properly maintained.
• Handle errors properly and die if necessary.