neocomm/CONTRIBUTING.md
Nicolás A. Ortega 3f4eca40f7
Wrong project :P
2017-07-03 17:22:30 +02:00

46 lines
2.7 KiB
Markdown

Contributing Guide
==================
This is a basic contribution guide to the project. What follows are guidelines you should follow when contributing so that work flow is not broken.
- [Licensing & Copyright](#licensing--copyright)
- [Code Style](#code-style)
- [Fractured Patches](#fractured-patches)
Licensing & Copyright
---------------------
All code contributions will be licensed under the [GNU Lesser General Public License version 3 or greater](/LICENSE). If you create any new files you **must** have the following copyright notice prepended to the file:
```c
/*
* Copyright (C) 2017 <your name> <your@email.org>
* Author: <your name> <your@email.org>
*
* This program is free software: you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation, either
* version 3 of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this program. If not, see
* <http://www.gnu.org/licenses/>.
*/
```
Have this text commented out at the beginning of every source file you create.
Code Style
----------
Generally just try to keep your coding consistent with the project's style, if you see things done in manner X try to do them like X. That being said, there are a few things that are important to remember:
1. This project uses tabs for indentation, please do not use spaces and most definitely do not use a mix of both.
2. When using loops and conditionals, if you're going to use brackets, please use broken brackets (ie. put brackets on their own line).
3. One instruction per line is ideal, sometimes it's not necessary, but if it's a simple conditional with a `return` statement or something please put the `return` on the next line.
4. Please document any additional interfaces you add to the library using [Doxygen style comments](http://www.stack.nl/~dimitri/doxygen/) so the API documentation can be automatically generated. If internal code is obscure or requires explanation then please do so as well, for the sake of yourself and all those that come after.
Fractured Patches
-----------------
Please make sure that any patches you give do only one thing. Do not mix bug fixes with features with enhancements or anything of the sort. Even if it's just bug fixes (as an example, could be anything else) please make sure that each patch only fixes one thing. Exceptions are fine if they are required (this will be judged based on circumstance).