neocomm/CONTRIBUTING
Nicolás Ortega Froysa fac59cfd2f
Moving to full C++.
2018-03-29 15:04:17 +02:00

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.