C# Coding Style
We follow a similar coding style as dotnet/runtime.
For non code files (xml, etc), our current best guidance is consistency. 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. If there is a completely new component, anything that is reasonably broadly accepted is fine.
The general rule we follow is “use Visual Studio defaults”.
- We use Allman style braces, where each brace begins on a new line. A single line statement block can go without braces but the block must be properly indented on its own line and must not be nested in other statement blocks that use braces. One exception is that a
usingstatement is permitted to be nested within another
usingstatement by starting on the following line at the same indentation level, even if the nested
usingcontains a controlled block.
- We use four spaces of indentation (no tabs).
- We use
m_camelCasefor internal and private fields and use
readonlywhere possible. Prefix internal and private member (instance) fields with
m_, static fields with
s_and thread static fields with
t_. When used on static fields,
readonlyshould come after
readonly static). Public fields should be used sparingly and should use PascalCasing with no prefix when used.
- We avoid
this.unless absolutely necessary.
- We always specify the visibility, even if it’s the default (e.g.
private string m_foonot
string m_foo). Visibility should be the first modifier (e.g.
- Namespace imports should be specified at the top of the file, outside of
namespacedeclarations, and should be sorted alphabetically, with the exception of
System.*namespaces, which are to be placed on top of all others.
- 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 (e.g. private members are named
m_member), the existing style in that file takes precedence.
- Alway use actual type names, we only use
varwhen it’s required because the actual type is unknown or is run-time deferred.
- We use language keywords instead of BCL types (e.g.
int, string, floatinstead of
Int32, String, Single, etc) for both type references as well as method calls (e.g.
- 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 use
"..."whenever possible and relevant.
- Fields should be specified at the top within type declarations.
- When including non-ASCII characters in the source code use Unicode escape sequences (\uXXXX) instead of literal characters. Literal non-ASCII characters occasionally get garbled by a tool or editor.
- When using #region sections or labels (for goto), indent the item one less than the current indentation.
An EditorConfig file (
.editorconfig) has been provided at the root of the repository, enabling C# auto-formatting.