Variable Coding Standards

General Rules

• Encapsulation - Variables that are public should be avoided when possible. In most cases, public variables are a sign of spaghetti code and poor encapsulation. If a variable should not either be set or read from outside its class or has restrictions on what values it can have it should be marked as private, and functions should e used for changing its values.
• Const - Variables should be marked as const if possible, but many unreal functions do on accept const variables.
• UPROPERTY - Variables should always be marked as UPROPERTYs if possible.
  • Categories - Variables that are visible in the editor or blueprint should always have a category. Sub-categories should be used.
  • Value Clamps - If a variable is EditAnywhere, EditDefaultsOnly, or EditInstanceOnly and has minimum or maximum values it should be given a respective ClampMin or ClampMax meta tag.

Names

Variable names are critical as good variable names can make code much more readable and eliminate the need for some comments elsewhere in the code. Variables should always be nouns (except bools which are adjectives) that describe what the variable is storing, though, nouns with irregular plurals (Like data or sheep) should be avoided if possible. They should be clear, specific, and concise. Always use pascal case.

For normal variables i.e. int, float, UObject*, TSubclassOf, variable names should always be singular.

For boolean variables, variable names should be adjectives prefixed by b.

For list-type variables i.e. TArray, TSet, TSparseArray, variable names should always be plural.

For pair-type variables i.e. TPair, TTupple, variable names should be formatted as follows: [Singular Key Noun]To[Singular Value Noun]

For map-type variables i.e. TMap, TGridMap, variable names should be formatted as follows: [Plural Key Noun]To[Pural Value Noun]

For variables declared as an iterator for a for each loop, variable names should be the same as the thing they are iterating though, minus plurality, prefixed by Each.

Good Examples:

• int NumberOfPlayers;
• float ThrustForce;
• bool bDead;
• TArray<AActor*> AimTargets;
• for(AActor* EachAimTarget : AimTargets)
• TMap<APlayerController*, int> PlayersToScores;
• for(TPair<APlayerController*, int> EachPlayerToScore : PlayersToScores)

Bad Examples:

• int Players; - int is a sinugalr type, and it is unclear what an integer player is.
• float Force; - It is too ambiguous.
• bool IsDead - Does not have the b prefix. "Is" is a verb.
• TArray<AActor*> AimTarget; - TArray names should be plural.
• for(AActor* TargetElement : AimTargets) - Does not follow the for each iterator naming convention.
• TMap<APlayerController*, int> PlayerScores; - Name dose not indicate that the variable is a map.
• for(TPair<APlayerController*, int> Score : PlayersToScores) - Does not indicate that the variable is a pair or an for each iterator.

Commenting

All variables (including local variables) should have comments describing what they store. These comments should avoid mentioning how the variable is used in logic. Comments should be a complete sentences.

//[Description]
int MyInt{ 0 };