Coding Standard

We have StyleCop in this project, so a significant amount of coding standard documentation does not need to be written as it will warn you if you do anything different to what it wants. For the most part you should follow the standard C# development practices (ex: Allman style, upper case functions and non-private variables, etc).

The following are some things to keep in mind while making your code:

Nullable references is turned on (as we're on C# 8 at the time of writing)

This means you cannot declare a field and set it to null without it having a question mark next to it (unless you set it in the constructor):

public class MyClass 
{
    public MyObject? Object;
}

This helps us avoid null reference exceptions completely. You can also condense code with the null-coalescing operator or invoking things like Object?.Member in the case of it being null.

You can convert one liners into the arrow notation

This means if you have

public bool Something() 
{
    return something + anotherThing < 5;
}

you can do:

public bool Something() => something + anotherThing < 5;

If the return line is too long then do it the top way instead of the bottom way (above).

Now while I abused it to set values, I've decided that I'd disallow that now (and if I forgot to fix that anywhere, please fix it for me in a PR or let me know so I can fix it). It's easier for me to associate => for functions as returning a value rather than invoking a single expression that is void.

Local functions are okay to use, especially in performant areas over lambdas

This has been great in the physics code, feel free to use it wherever. I don't think we'd want a nested local function inside of a local function, but it'd have to be evaluated on a case-by-case basis.

Check Util/Extensions/ for any extension types

Extensions are very awesome, you should try those out or add any if a [standard] library class is missing anything.

Private member variables should use a m_ prefix

This is something that took a bit to get used to, but C# conventions in most projects either do _ or m_ for private variables (and everything else is PascalCase).

The reason I didn't go with _ is that it felt really hard to read compared to m_, and the gap that is created from a period followed by an underscore was something that I could not get used to no matter how hard I tried. Since projects also use m_ and that was easier on my eyes than an underscore, I went with that. If there was no m_ then I'd probably have just gone with the underscore anyways because that is what a large bulk of the C# projects do.

You may be wondering why any prefix is used at all, instead of camelCase. While this is something I'd do if it was Go or Java or JavaScript (...etc) as that is the standard there, my goal is to follow the C# conventions that the community takes part of. Virtually every project I came across used _ or m_, so I decided I'd follow what the community generally does. As a side effect, I no longer have accidental shadowing of variables in the constructor which has burned me a few times in C++ when I couldn't use the initialization lists after the constructor.

It doesn't take too long to get used to it!