Skip to content

C# Coding Style

symbolspace edited this page Nov 21, 2018 · 2 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.

  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 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 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).
  11. 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.
Clone this wiki locally