CodeGuidelines

Guidelines

When coding BetterLegacy, there are a few rules that need to be kept in mind for consistency.

Casing

• Methods, properties and types are cased like "ParaBoss" whereas fields are cased like "paraBoss".
• In cases where a name contains initials the initials follow its own rules. If the first initial is lowercase, then all initials must be lowercase, like "paLegacy". However if the first initial is uppercase, then all initials must be uppercase, like "PALegacy".
• Constants must always be uppercase, with an _ representing a space. For example: "PARA_BOSS".

Other naming rules

• Prefix a type with "RT" if a type with the same name already exists. For example: EventManager > RTEventManager, PrefabEditor > RTPrefabEditor, etc.
• Patch methods must end with a suffix of what type of patch they are. So if a patch is postfix on a MonoBehaviours' Awake method: "AwakePostfix".
• The casing rules don't apply when patching PA functions. If a method is "getPitch" and we're applying a prefix patch to it, the patch will remain as "getPitchPrefix".
• Patch classes are named after the class they patch with the word "Patch" at the end, such as: "EditorManagerPatch".

Shorten code where possible.

• If a method is one line of code, then it's generally nicer to have it be one line rather than have a body. For example, we go from this:

public float DoSomething(float t)
{
	return t + 1f;
}

to this:

public float DoSomething(float t) => t + 1f;

• Private accessors aren't needed. If you want something to be private, just don't include an accessor. Going from "private static int number" to "static int number".
• Usually when looking at the PA Legacy code through a code inspector, delegates will show like this:

AddListener(delegate (float x) { });

When writing our code we instead want them to look like this:

AddListener(x => code here...);

Simplify code

• If you find yourself writing the same line over and over again, it's usually a good idea to put that line of code in its own method.
• Region sections of your code.
• Summary and comment as much as you can to make things as clear as possible.
• Where possible, improve on accessibility of specific functions to allow for more room with feature implementing.

Keep in mind somethings in BetterLegacy do not follow these guidelines due to a few reasons (like being based on really old code).