-
Notifications
You must be signed in to change notification settings - Fork 977
C# Coding Style
Max Gortman edited this page Jul 19, 2015
·
3 revisions
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.
- We use Allman style braces, where each brace begins on a new line. Single line statement block must be enclosed in braces.
- We use four spaces of indentation (no tabs).
- We use
lowerCamelCase
for private fields and usereadonly
where possible. We don't use underscore (_
) in field names. -
this.
must always be specified when accessing instance member. - 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.
- Namespace imports should be specified within
namespace
scope and should be sorted alphabetically, with `System. namespaces at the top. - Avoid more than one empty line at any time. For example, do not have two blank lines between members of a type.
- 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. - 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.
- We only use
var
when it's obvious what the variable type is (i.e.var stream = new FileStream(...)
, notvar stream = OpenStandardInput()
). - We use language keywords instead of BCL types (i.e.
int, string, float
instead ofInt32, String, Single
, etc) for both type references as well as method calls (i.e.int.Parse
instead ofInt32.Parse
). - 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.