Coding Guidelines

TODO: Clean this page up later.

Documentation

Code Documentation should be done using XML with /// and not /** */.

All <tags> Should start on the same line as the text and end on the same ending line of the text.

Use of <param> is not necessary for function documentation but encouraged when parameters have special use-cases. Use of <returns> is useless since it doesn't show outside of generated documents. Instead, important information on returned values should be stored in the <summary> tag.

/// <summary>This is a single-line description for a function.</summary>
///

Braces should be used on single-line blocks on a case-by-case basis for what makes the code easier to read

Comments

• Periods should be used for longer comments or multi-sentence comments; They should be left out otherwise.

New Lines

When continuing an expression on the next line, keep commas, operators, and parenthesis on the end of the line. Periods should go on the next line in order to show the following statement is attached to the previous line.

Multi-line functions should close parenthesis on the last line and not a new line.

Ordering

Properties go at the bottom.

Internal properties go below public properties.

Internal methods go at the bottom, but above properties.

Line Width

The maximum line width is 88 columns, which is the same length used for the categorization comments.

C-Sharp Syntax

No use of ? operator for calling functions when non-null. foo?.Invoke();

Outlining

Use of regions is forbidden.

Member Naming Convention

Members should be formatted in lower camelCase when private, protected, or internal, and Upper CamelCase when public.

Members should not be made public outside of basic structs. Use property-access instead.

Constant Naming

Game-related constants and settings that can be configured (although usually shouldn't) should be named using MACRO_CASE while remaining constants should stay as Upper CamelCase.