Contributing Guidelines

1. Please try to keep your pull requests small, ideally limited to files for one script function. If a script function requires helper functions to work, they should be included. Multiple unrelated scripts functions are OK but be sensible with your commits. Don't commit everything at once.

2. Do not delete obsolete functions from the library. Raise an issue instead. Obsolete functions are handled differently and their descriptive Markdown files have a note placed at the top indicating they are obsolete. The reason they are kept in the repo is to keep old web links functioning. The script section of the site is generated directly from this repo.

3. Please try to adhere to the style guide found in the root of this repository.

4. Please do not submit code you did not personally create. By submitting code to the GMLscripts.com script repository, you agree to the terms of the collective license. You retain the copyright of any your code.

Please submit your contributions as a pull request on GitHub.

Script Submission Style Guide

The recommended style for script functions featured on GMLscripts.com is in the spirit of K&R and One True Brace.

• Precede functions with a header in the form of a /// comment block.
• Use JSDoc-style markup in headers, including a function signature, description, list of parameters, and return values.
• Ensure the first sentence of a function is descriptive but as brief as possible; place usage details and special notes in additional sentences and paragraphs.
• List any function or asset dependencies in the header.
• Use short and descriptive names for parameters and variables.
• Separate parameters and arguments using a comma followed by a space.
• Limit line lengths to 80 characters, if possible.
• Terminate statements with a semicolon.
• Place an opening brace on the same line as its construct or conditional.
• Align a closing brace with its controlling statement.
• Place an else or until conditional on the same line as its preceding brace.
• Indent blocks of code consistently using four spaces per level.
• Avoid single-line blocks of code.
• Always declare local variables with a var statement and static variables with a static statement.
• Never create or modify global or instance variables unless it is a well-defined feature of the function.
• Terminate the execution of a function with a returned value.

Always check this style guide for changes before submitting contributions.

/// @func   my_function(alfa, bravo, charlie)
///
/// @desc   Returns or does something briefly described in the
///         first sentence. Full usage details should follow.
///
///         Note: Use multiple paragraphs for clarity or to add
///         any special usage notes.
///
/// @param  {datatype}  alfa        brief parameter description
/// @param  {datatype}  bravo       brief parameter description
/// @param  {datatype}  charlie     brief parameter description
///
/// @return {datatype}  description of returned value
///
/// GMLscripts.com/license

function my_function(alfa, bravo, charlie)
{
    var delta = 0;

    // Useful comments are encouraged.
    for (i=alfa; i<bravo; i+=charlie) {
        if (delta mod 3) {
            delta += i;
        } else {
            delta -= i;
        }
    }

    // Break up code sections to improve clarity.
    do {
        delta += 10;
        delta /= 2;
    } until (delta > 0);

    // Scripts should always return some value.
    return delta;
}