66 lines
2.4 KiB
Plaintext
66 lines
2.4 KiB
Plaintext
# 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.
|