Contributing Guidelines

Coding Style

When it comes to standards for coding style, the best guidance is to try to go with what is already in the repo. The code in the repo follows Microsoft coding standards, and try to follow that.

Naming & Casing

• Use PascalCasing for all namespaces, types, and member names (except for non-public backing fields).
• Use camelCasing for all private and internal backing fields, argument names, and local variables.
• Prefer: C# aliases instead of Framework type names (e.g. object not Object).
• DO NOT use Hungarian naming conventions (ie, do not encode type information in variable names)
• DO NOT use Hungarian abbreviations like “Tc” or “b” for member names and method signatures. FxCop is checking for abbreviations as violations.

---

One Class, One File.

• Define a single type per file, the file name of which is the short type name (i.e., not qualified by its namespace).
• Partial type definitions are permitted.
• For managed code, directory names should follow namespace names, discounting the core namespace prefix.
• (C++): Use #pragma once. Avoid using inclusion guards (#ifdef).

---

Spacing: Prefer Existing

Use 4 spaces for tabs. Ensure that you are consistent with the surrounding code.

• To configure indentation settings in VS, go to the Tools\Options dialog, then drill down into \Text Editor\All Languages\Tabs and from there select "Keep tabs".
• If you'd like to actually see the white space indentations in the VS editor, select Edit\Advanced\View White Space or more simply or CTRL+E, S.
• Avoid “trailing whitespace”: spaces or tabs at the end of a line.

---

(C++/C#) Do: Keep class members in order. (C#) Keep “using” statements in order.

Class members should be in the following order:

• Events
• Private Fields
• Constructors
• Properties
• Methods
• Private interface implementations
• Nested types.

Using statements should be sorted alphabetically, with preference given to Framework includes (place them ahead of project specific includes).

---

(C#)

• Do: Use this

Reference all class members by using this. before class members (fields, events, methods, properties).

• Do NOT use _ or m_ prefixes for class members.

Do not use Hungarian naming prefixes.

• Avoid: var

Minimize the use of var in all of our codebases. Var will produce a variable where the type is automatically determined.

(C++)

• Do: Use m_

Reference all class fields by prefixing the variable name with m_. Do not use Hungarian naming prefixes.

• Do not use _ or __ to prefix names.

• Prefer: auto

While var provides syntactic sugar which may make the codebase harder to read, auto&& and the verbosity of C++ types when STL is used will cause significant overhead.

• Prefer: RAII and shared pointers (std::shared_ptr, std::unique_ptr, ComPtr)

Resource management is a large pain point in C++ projects. Decoupling resource acquisition from resource destruction can cause bugs. RAII and smart pointers ensure that if a resource is acquired it will be released.

• Prefer: STL data structures over Windows data structures and internal data structures

The STL data structures have a high degree of integration with new language features such as move constructors.

• Prefer: const correctness

Const correctness is an important tool in C++ used to enforce methods that have no side effects. In general this has a very high "startup" cost, but for large enough codebases the benefits will quickly manifest. Your end code will be more concise and safer to program with, especially for developers outside of the team. The compiler will generate more efficient code as well.