When editing files, keep new code and changes consistent with the style in the files. For new files, it should conform to the style for that component. Last, if there's a completely new component, anything that is reasonably broadly accepted is fine.

1. We use Allman style braces, where each brace begins on a new line. Single line statement block must be enclosed in braces.
2. We use four spaces of indentation (no tabs).
3. We use lowerCamelCase for private fields and use readonly where possible. We don't use underscore (_) in field names.
4. this. must always be specified when accessing instance member.
5. We skip specifying visibility when it matches the default: private for class members and nested classes, internal for top-level classes, interfaces, structs and enums.
6. Namespace imports should be specified within namespace scope and should be sorted alphabetically, with `System. namespaces at the top.
7. Avoid more than one empty line at any time. For example, do not have two blank lines between members of a type.
8. Avoid spurious free spaces. For example avoid if (someVar == 0)..., where the dots mark the spurious free spaces. Consider enabling "View White Space (Ctrl+E, S)" if using Visual Studio, to aid detection.
9. If a file happens to differ in style from these guidelines, the existing style in that file takes precedence. Fixing style can be done separately and must not carry any functional changes.
10. We only use var when it's obvious what the variable type is (i.e. var stream = new FileStream(...), not var stream = OpenStandardInput()).
11. We use language keywords instead of BCL types (i.e. int, string, float instead of Int32, String, Single, etc) for both type references as well as method calls (i.e. int.Parse instead of Int32.Parse).
12. We use PascalCasing to name all our constant local variables and fields. The only exception is for interop code where the constant value should exactly match the name and value of the code you are calling via interop.

We have provided a ReSharper settings file (DotNetty.sln.DotSettings) at the root of the repository, making it easier to follow the above guidelines when using Visual Studio with ReSharper. Use of ReSharper's Cleanup Code using supplied profile ("Simple") is welcome unless it affects non-trivial amount of otherwise unchanged code. In this case, separate PR, enforcing code styling should be posted.