Skip to content

Latest commit

 

History

History
91 lines (60 loc) · 3.04 KB

CONTRIBUTING.md

File metadata and controls

91 lines (60 loc) · 3.04 KB

Code agreement and guidelines


⚠️ PLEASE READ BEFORE CONTINUING ⚠️


Any code that you contribute will be under full control by the repository maintainers. They may change it's licensing, the code itself, or use it for whatever the organization sees as necesarry. This does not mean rights, you will still have access to and retain full ownership of your work. This agreement is in place to prevent attempted project hijacking and legal issues. Code taken from existing sources do not fall under these rules, as that would be unethical and illegal. All code taken from outside sources fall under their original licese(s) and shall have a reference to it's orignal license.


Including externaly sourced code

You are allowed to include source code from external sources, as long as you make sure it's original license is compatible with this project's license (GPL - V2). It is recommended to remove the whole license copy from the source files (if it has it) and add a comment referencing the source's original author, source, and short name of the original license. If the source files themselves do not have a copy of the license within them, you must add comments showing the original author, source, and short name of the license.


Spacing & Formatting

All functions, local and global variables, and namespaces must be capitalized with the 'PascalCase' naming Convention, and spelled properly. They must contain professional and easy to read names, usually they should describe what the function does, if possible.

Variables and using statements should be clustered Like this, with descending length:

image

There shall also not be more than one class/struct/enum or namespace in the same file.


Keep all code as simple as possible and make sure all code is understandable.


Bundling

If a class has more than one type of data, use #region tags like so:

image


Do NOT create hacky methods to get around something unless you know you will change it before you commit. You will regret making something very unreliable then having to re-make it for several hours in a more stable manner)


Always use IF statments "properly" and clearly. and example is if you have many nested IFs, invert the condition and move it to the top, and return it if the condition is met.


Don't define namespaces within namespaces, and always include only one namespace definition per file, just below the using statements. They should not use brackets like so:

namespace PrismOS;

Licensing

You must include files from other projects (with compatible licenses) like so: image