-
Notifications
You must be signed in to change notification settings - Fork 1k
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
lowerCamelCasefor private fields and usereadonlywhere 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
namespacescope 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
varwhen 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, floatinstead ofInt32, String, Single, etc) for both type references as well as method calls (i.e.int.Parseinstead 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.