Update CONTRIBUTING.md

CONTRIBUTING.md

@@ -1,3 +1,26 @@
-Contributions are welcome!
+# Contributions are welcome!
+You should be familiar with the following few guidelines before you contribute any code. These are not set in stone, if there is a good argument, I am very much open to change. You can submit a pull request with your changes, briefly describe them and I will review as soon as I can!
 
-TODO: Write contributions guidelines
+## First, let's get the boring code formatting guidelines out of the way:
+- use the default Visual Studio 2017 formatting
+- generally, function names start with Uppercase, variable names with lowercase
+- Very short, inline function names can start with lowercase
+- member and global variables usually use camelCase formatting: int myGlobalVariable;
+- temporary variables on stack sometimes use lowercase formatting like this: int tmp_variable_on_stack;
+- prefer having braces on their own line when writing loops, branches, functions or whatever
+
+## Now, on to some more interesting stuff:
+- avoid using c++ stl containers if possible (std::vector is fine) (todo: there are still some offenders remaining in the code)
+- avoid new and malloc and generally allocating on heap wherever you can. Especially avoid it in frequently called code! Note that by default, c++ std:: lib will allocate on heap.
+- you can use auto keyword, but aim for as small scope as possible
+- using auto keyword for iterators is encouraged
+- aim to write const-correct code
+- using references, and pointers is encouraged to indicate if a resource must be initialized or not
+- you can write templated code, but aim for simplicity, and it must be commented thoroughly
+- aim for minimal header inclusion to keep build times fast. Use forward declarations wherever you can
+- use namespaces
+- avoid "using namespace xyz" in header (.h) files
+- prefer "using namespace xyz" in source (.cpp) files
+- avoid using geometry shaders if possible
+- when writing shaders, use the resource declaration macros and define proper named bind-points at compile time. See examples in ShaderInterop.h, ShaderInterop_Renderer.h, etc...
+- speaking of macros, I don't have a problem if you use them wisely (use short and simple macros)