Rules for editing

1. Backwards compatibility
   When improving an extension, please ensure backwards-compatibility. If someone installs your improved extension and cannot open their MFAs, you have failed this rule and it is very likely your improvements will be reversed. Open an issue if an edit which disobeys this rule occurs.

2. Ideas must be approved; bugs must be squashed.
   Old SDK extensions, such as CD-Audio, should not be modified without the author's permission. If you are repairing a bug, you do not need permission, although you must ensure this does not create new issues. If you notice a bug, you should either fix it (if you know how) or open an issue for other developers.

3. No April Fools
   Don't make an edit unless you are absolutely sure of what you're doing. Don't make joke edits for fun - its a waste of time.

4. Reduce the warnings
   Feel free to make changes that do nothing but stop Visual Studio coming up with errors.

    // Original
    DWORD d = 0;
    size_t s = d; // Although these are the same size, you will get "possible loss of data" compiler warnings.
    // Fix 1: change a variable type to an equivalent
    size_t d = 0;
    size_t s = d;
    // Fix 2: add a cast
    DWORD d = 0;
    size_t s = (size_t)d;

5. Efficiency changes are edits A change like this is known as an "efficiency edit":

    // Original
    q = 0;
    do_stuff(q);
    q += 1;
    // Edit for efficiency
    q = 0;
    do_stuff(q);
    ++q;

You should ask the author for permission of this edit. Some developers do not know that tiny efficency changes like:

    // Original
    int i[2], j[2] = {0,0}, k = 0;
    while(k < 2)
        j = i[k++];
    // Efficency change which will not reflect the original's purpose
    int i[2], j[2] = {0,0}, k = 0;
    while(k < 2)
        j = i[++k];

So efficiency edits should be done with care and permission.

6. Formatting whitespace does not require permission
   You are permitted to edit whitespace formatting of extensions for clarity, without permission. Please ensure you edit the entire project to that format (partial file changes will not be accepted). Tabbing should be consistent; generally developers prefer 4 spaces. However, you must retain the author's tab size or request permission to change it.

    a+=b;
    // Whitespace edit for readability/clarity
    a += b;

Capitalisation of variables, though, should not be modified without author's permission; as chief contributor, it is their code and you must respect their methods.

    a+=b;
    // Pointless capitalisation edit (and a sign of a superiority complex)
    A+=B;

The author will find it difficult to improve their project if someone has modified all the capitalisation.

7. Update to EDIF/DarkEDIF
   DarkEDIF is currently in pre-release. Once it hits the shelves you are requested to upgrade all extensions to DarkEDIF. Until then, you are requested to upgrade all extensions to EDIF, as it is more readable and much cleaner. Do not replace extensions, just make a copy in the EDIF folder and upgrade it there. The author can choose to accept your conversion or reject it (most likely it will be accepted). If accepted, the original will be deleted and the modified version released as an extension update. If not accepted, it will remain under EDIF (in most cases).

8. Do these rules apply to SortaCore/Phi?
   Phi has exception to these rules. No, not really, it applies to him too. This isn't a double-standards thing. The only difference is he is the main judge in whether the rules have been broken; he and the author of the extension(s) concerned will decide what action to take.

9. Someone broke the rules
   If any of these rules are broken, open an issue (or contact Phi on ClickConverse or PM on Clickteam forums). Do not reverse any edits; Phi (and usually the extension's author) are the only ones that have the authority to do so. If someone changes the capitalisation and the original author realises it's better readability, they can permit it.