When contributing to the project, and if otherwise not mentioned in this document, our coding conventions follow the Microsoft C# Coding Conventions and standard Naming Guidelines.
Members and types should always have the lowest possible visibility.
Ordering of class members should be the following:
- Constants
- Fields
- Abstract members
- Constructors
- Properties
- Methods
- Private nested classes
Furthermore, each of these categories should be ordered from higher to lower accessibility level (public, internal, protected, private).
-
Code should contain as few comments as necessary in favor of well-named members and variables.
-
Comments should generally be on separate lines.
-
Comments on the same line with code are acceptable for short lines of code and short comments.
-
FIXMEshould only be used in the code during development as a temporary reminder that there is still work to be done here. AFIXMEshould never appear in a PR or be merged into master. -
ToDocan be used to mark part of the code that will need to be updated at a later time. It can be used to track updates that should be done at some point, but that either cannot be done at that moment, or can be fixed later. Ideally, aToDocomment should be followed by an issue number (what needs to be done should be in the github issues).
Generally, as we do not want to have classes that are too long, regions are not necessary and should be avoided.
It can still be used when and where it makes sense. For instance, when a class having a specific purpose is
implementing generic interfaces (such as IComparable, IDisposable), it can make sense to have regions
for the implementation of these interfaces.
Empty lines should be used between blocks, Namespace/End Namespace statements, Class/End Class statements
and regions to improve readability.