Style Guideline

A general style guideline is enforced and your PR may not get approved if it's violating that guideline. The guidelines have been made to be short, clear, and concise, please do read them!

General guideline:

• The standard indent for ALL files in the repo is two spaces. Most text editors can be configured for this, including Notepad++, Atom, and Sublime. Any commits using tab characters or some other amount of spaces will have to be corrected before they can be accepted. This applies to any snippets taken from the the game files as well, they MUST use spaces instead of tabs!
• There should be no extraneous spacing/separation between functions in lua files and between properties/elements in xml files, except where their use is actually sensible. This applies especially to any snippets taken from the game files, as they often have ludicrous amounts of padding for no good reason, rendering them much more difficult to read!
• The above two rules do not apply to newly imported game files. Newly imported game files will eventually be corrected to the project style guidelines in a pre-release styling pass.
• All files that override existing game files should be added in such a way that they mirror the directory structure of the actual game files, even if it's counter-intuitive, like with ProductionPanel.xml (which is in the root UI directory) and ProductionPanel.lua (which is in the UI/Panels directory). This helps keep files easy to find and ensures that multiple copies of the same game file are not added by accident. Files and changes that have been imported from other mods are exempt from this rule and live in their own root directory (see the BTS files and directory for an example)
• Files that are unique to CQUI should always go in the Assets directory AND be prefixed with "CQUI_". This is done because the actual internal file structure assembled by the game is flat, and files sharing the same name can conflict, even if they are in different directories.
• When adding new files from the game directory, you should always have an import commit, where nothing about the file is changed except for the basic fact that it was added. Once this initial import commit is made, you are free to proceed in modifying the game file. This makes porting individual changes easier for people with their own personal CQUI forks. Files that aren't game files don't need an import commit, since they're blank to start with!
• When your commit includes a bugfix or implements a feature that's tracked on the issue tracker, include the phrase "Fixes #X" or "Resolves #X", where X is the tracker number of the issue or feature. This will notify everyone participating in the issue of your change when you push it to your fork, as well as automatically close the issue when the change is merged into the main repo.

Lua guideline:

• When modifying existing game files, prefix newly added functions, events, and members with "CQUI_". This makes finding changes easier for everyone! Changes made to files which are unique to CQUI are exempt because all changes made in them are from CQUI. Changes imported from other mods are entirely exempt from this rule, even if they are in a game file, this exemption exists to make integrating future mod updates easier.
• ALL changes, regardless of context, should have comments if they aren't just a tweak or bugfix. Don't go overboard with comments and use common-sense, but anything that isn't immediately self-describing should be a candidate for comments.
• All changes should be checked for error output in Firetuner. Even if a change works, it will not be accepted if it produces error output.

XML guideline:

• XML files are generally considered to be self explanatory, so changes to XML files do not typically need any comments
• All element IDs should be unique within the scope of the XML file. Duplicate IDs cause problems! Instances have their own scopes and can duplicate other IDs in the same file, so long as they do not duplicate an ID existing inside of their own scope
• Be especially sure to enforce the first two rules from the General guideline in XML files!

Localization guideline:

• All existing localizations should be preserved wherever possible. A localization always starts with "LOC_" and can appear in both the XML and Lua files.
• There should be NO hardcoded strings in CQUI. Your contribution will not be accepted if it fails to properly make use of localizations, hardcoded English in UI elements is absolutely not allowed under any circumstances. If you see any hardcoded English in CQUI that doesn't simply print to console, please open a ticket.