As always, all comments welcome.

After reading through and grokking the following conventions, you will also want to read and grok the Documentation Guidelines.

Java to .NET transliteration

These are the Spring.Java to Spring.NET transliteration idioms we have agreed on so far.

• Follow C# conventions and idioms, this is not a 'blind' port to C# (see below). In particular...
  • bean property methods become .NET properties.
  • method names begin with an uppercase letter, for example 'registerVisitor' becomes 'RegisterVisitor'.
  • Anonymous classes become private nested classes.
• Change in root namespace/package from "org.springframework" change to "Spring".
• Externally visible names should be semantically and consistently identical (as much as is possible) to the corresponding name in J2EE Spring - to reduce the pain of switching between the J2EE and .NET Spring Frameworks.
  • For example, BeanWrapper -> IObjectWrapper. Be consistent.
  • Any Spring developer must be able to look at at a Spring.NET XML file and immediately understand how it relates to Spring Java.
  • Do not change names without good reason, for example ApplicationContext -> IApplicationContext
• Keep existing design where possible, e.g. AOP packages should pretty much stay the same, as there's nothing Java-specific there.
• When handling a case where these principles conflict, favor simplicity and ease of understanding. The lead developer will have the final call.
• Peruse the using c# keyword with IDisposables (See example)
• Convert integer constants to integer based enumerations unless the integer constants are used solely within the class (i.e. have private scope).

Coding Conventions

Blatantly stolen from the NAnt project page and relisted here in case we actually get creative

• Be consistent - look at the existing code and make yours fit it.
• Apache 2.0 header on every source file.
• Namespace starts with Spring
• Make the code so simple that its boring to read.
• Follow .NET naming conventions (see SDK docs)
  • Interfaces begin with the letter 'I'
  • Class names should not end in 'Impl'. For example, the interface 'IHelper' might have a corresponding implementation called 'DefaultHelper'. This is the current convention, although it is a convention only; do what makes sense and what makes the code read better... just don't use 'Impl' .
  • Use object instead of System.Object. Similar for other types in C#. In particular from JLCA generated code.
• Do not prefix private fields with a leading _ character. This was the previous coding style, which has been superseded by not using a leading _ character. Instance fields must now be prefixed with the this keyword. Some of the existing code uses the old style... if you are editing a source file that uses the old style, please do change it to use the new style before committing.
• Always use access modifiers on instance fields (i.e. 'private int foo;' as opposed to simply 'int foo;'). Do not rely on the default access modifier. Be explicit.
• Use 4 space indents instead of tabs.
• One class, struct, or interface one file.
  • An accepted exception to this rule is when you need to convert an anonymous class to a regular class. In this case, you should define it in the same file where anonymous class was originally defined (see above).
• Class source code files stored in directories to match namespace.
• Squigglies on separate lines.
• Always use { } even if statement is a single line
• Avoid ? : operations in all but the most trivial cases.
• Avoid magic numbers, use a nested enum instead.

public enum Foo
{
    Foo = 0, 
    Bar = 1
}