Moving to full C++.

CONTRIBUTING

@@ -0,0 +1,65 @@
+# Contributing
+--------------
+In order to maintain some consistency and order in the project, there are
+certain guidelines which must be followed.
+
+## Code Style
+-------------
+To make sure that the project is readable, it is necessary to make sure
+everything follows the same style. If you do not see something mentioned here
+as to code style, then see how it has been done in other parts of the project.
+If there are no other cases of such in the project then it's my fault for not
+making it clear.
+
+### Indentation
+All code in this project is indented using tab characters (**NOT SPACES**).
+This is done so that each developer may see the code with the indentation width
+that they prefer.
+
+### Naming Convention
+Naming convention in this project follows the C/C++ schemes (i.e. all lowercase
+with underscores).
+
+### Bracket Breaking
+With the exception of functions and classes, brackets must be broken (i.e. have
+their own line). This is done so that one may easily comment out the first line
+of an if-statement to make a block of code unconditional. For instance, in the
+following example with simply commenting out the first line we are able to make
+a block of code unconditional and even maintain the scope of the code within.
+
+  if(condition)
+  {
+      // some code
+  }
+
+### Statements-Per-Line
+Try to keep things at one statement-per-line-of-code. That is I shouldn't see
+lines such as the following:
+
+  if(condition) code;
+
+You do not have to create brackets if there is only one line of code following
+the previous statement, but you do have to put the `code' on the next line as
+so:
+
+  if(condition)
+      code;
+
+This may be ignored for instances where `?' conditionals are used, such as:
+
+  int x = my_bool ? 1 : 2;
+
+## Documentation & Comments
+---------------------------
+Making your code understandable is important, and therefore commenting is
+important. For any public interfaces created you must provide Doxygen-style
+documentation. If you are writing internal functionality then you do not need
+to write Doxygen documentation, but you should write comments in your code. For
+the most part you shouldn't have to explain what your code does so much as why
+it is there if this may seem unclear to someone reading the code.
+
+## Licensing
+------------
+Any and all code contributed to this project must be licensed under the same
+license as the rest of the project (somewhat by law). For more information look
+at `LICENSE' file.