This is a collection of standards that we in reforged fleshed out internally over time and want to follow. The goal is to

• have a consistent readable code base
  • as we are open source and as reforged is meant to be very moddable and compatible it's required that modders can navigate and understand the code
• while still acknowledge grey areas
  • regularly it is not clear when to use which style of formatting or naming. In those cases it can be up to the modders discretion

Guidelines are rules that are mostly set in stone for the time being because the vast majority of members decided for that. Recommendations are vague rules that are sometimes correct to do but not always. They tap into a grey area where either way could be right.

Code

General

Guidelines

• If nothing else says otherwise, follow vanilla standards
• All code must be properly indented. We use tabs for indenting (equivalent to 4 spaces).
• Use this. notation to access something in the current class/table or up its chain of inheritance, and use :: when accessing the global root table.
• Statements must end with semi-colons.
• Curly braces always start on a new line, except when defining an in-line function or when defining tables.
• Add a space after keywords, except for function definitions: e.g. for ( instead of for(
• In function definitions, add a space before the first argument and after the last argument e.g. function( _arg1, _arg2 ).
• Function arguments start with _.
• When defining Squirrel classes, the non-static class members must be initialized to null and then set to their desired values in the constructor.
• The last element of arrays where each element has its own line should always end with a comma
  • this will improve the commit history when adding, removing, or sorting elements in an array
  • and reduce compile errors from otherwise missing commas after sorting arrays
• A comparison/operation between exactly two variables or functions that is returned should not have brackets
  • Example: return this.skill.isUsable() && !this.getContainer().hasSkill("effects.rf_bearded_blade");

Recommendation

• Variable and function names must be descriptive, understandable and identifiable.
• Additional optional brackets can improve the readability of long conditions or operations
• A very long if can often be made more readable by splitting its condition into different lines`
• A long if can sometimes be made more readable by splitting its condition into separate if guards
• Use ! instead of == false.

Naming Conventions

• New Content scripts introduced by us that are placed in vanilla directories alongside vanilla content has to contain an rf somewhere in the name, usually at the start

IDs

Every tooltip line has an id, in Vanilla this however has no purpose. Only with modding that id can be used to efficiently find an entry within a tooltip in order to delete or change it

Guidelines

• every tooltip line that we add have a unique ID which is not yet used by vanilla or reforged
• those ids being hard-coded, so that modders can look them up with 100% certainty in the source code

Recommendation:

• the ids for effects should start at 10
• Warnings and other misc lines start at 20

Order

• Code in BB Classes should be ordered and separated by comments to improve readability by modder
  • now a Modder can stop scrolling down once they reach // New Functions in order to understand on a high level, what the script is doing.
  • if they want to look up the definition of a function they know exactly in which repository to look for it (either vanilla, msu or somewhere within reforged)

Guidelines

1. member variables this.m
2. create function

Recommendation

3. all other vanilla functions/function hooks
4. If MSU functions are touched: 4.1 a comment saying // MSU Functions 4.2 all MSU functions/function hooks
5. If functions by other utility mods are touched: 5.1 a comment introducing that section 5.2 all functions/hooks for those utility mods
6. If new functions are introduced 6.1 a comment saying // New Functions 6.2 all new functions introduced by this script

Ingame Text

Tooltips

Guidelines

• We use more/less whenever possible for multiplicative changes.
• Additive changes use +/- or gain/lose
• Numbers for effects that are positive for the receiver are colored green. If negative for the receiver they are colored red.
  • It doesn't matter whether those numbers are added or subtracted to a stat

Git

General

Guidelines

• Every "feature" should have its own branch
• You should always branch off of the development branch
• When you think your branch is ready to be merged, create a Pull Request via GitHub to merge it into the development branch
• When force pushing, always use force push with lease to make sure that you don't overwrite changes by another person
  • For example, you want to add a new item or event, create a separate branch for it and implement it there.
  • Similarly you want to fix something, create a branch for it

Recommendation

• if the fix is small and you are really sure it works then you can commit it directly onto the development branch Fixes can also be committed directly to development if you are sure that your code works
• do not force push onto the development branch unless the other active members are online and

Pull Requests

Guidelines

• Pull Requests are to be merged via Rebase and Merge
• Do NOT resolve conflicts via Github
  • If the PR shows a conflict, then go to Sublime Merge and rebase the branch manually onto the target branch, resolve the conflicts, then force push the branch. Then go to the PR and merge via Rebase and Merge.
• Once a branch has been successfully merged, delete that branch
• Clean up the commits on your branch before merging into the target branch. Squash bloat commits into one commit (e.g. a commit that adds a feature, and a latter commit that fixes one line of code in the same feature should be squashed as a single feature commit before merging).

Commits Messages

Guidelines

• Follow "Conventional Commits" guidelines (https://www.conventionalcommits.org/en/v1.0.0/)

Comments

More comments is always better

Guidelines

• If the ingame name of an entity is different from the name of its script then that name must exist as a comment somewhere in that script
  • Otherwise it is very hard for any modder to find the script that corresponds to the ingame name because it currently just leads to an array with no further comments
• If a hook overwrites a vanilla function (not calling the base function) then a comment is needed that explains what effect is now lost and no longer happening because of that

Recommendations

• Add comments where appropriate to describe code whose purpose is unclear or difficult to infer.
• If a hook changes specific stats compared to vanilla via changing member variables in the create function then a comment must be added which states what the vanilla value was