Function Coding Standards

General Rules

• Encapsulation - Only mark a function as public or protected if absolutely necessary. This helps keep classes self-contained and the logic easy to change.
• UFunctions - Functions should always be marked as UFUNCTIONs if possible.
  • Categories - Functions should always have a category. Sub-categories should be used.
• Const - Always mark a function as const if the logic permits. This can dramatically increase performance.
• Success boolean - If a function can fail at its task it should always return a bool indicating its success. If it returns other values they should be pass-by-references.

Names

All functions and events perform some form of action, whether it's getting info, calculating data, or causing something to explode. Therefore, all functions should start with verbs. They should be worded in the present tense whenever possible. They should be specific as to what they are doing but not include unnecessary context.

Parameters are variables and should follow variable naming conventions.

Good function name examples:

• Fire - Good example if in a Character / Weapon class, as it has context. Bad if in a Barrel / Grass / any ambiguous class.
• Jump - Good example if in a Character class, otherwise, needs context.
• Explode
• SortPlayersArray - May need context if the Players array can be sorted.
• GetArmOffset
• EnableBigHeadMode
• IsEnemy - "Is" is a verb.

Bad function name examples:

• UpdateTransforms - Update how?
• ExplodeExplosiveBarrel - Bad if on the explosive barrel class.
• Dead - Is Dead? Will deaden?
• Rock - Wut is this????
• ProcessData - Ambiguous, these words mean nothing.
• PlayerState - Nouns are ambiguous.
• Color - Verb with no context, or ambiguous noun.

Commenting

For more on commenting see Commenting Standards

Function Descriptions

A function comment should appear before the declaration and the definition of a function. Use Javadoc formatting for all function comments. Add a @param for each parameter. Add @return if a value is returned. Use title case for the parameter names, and descriptions should be complete sentences.

/*
 * [Function description - Say what the function does, not when this function is called]
 *
 * @param [Parameter Name] - [Parameter description - Describe what this parameter is used for]
 * @param [Parameter 2 Name] - [Parameter 2 description]
 *
 * @return - [Return description - Describe what is returned]
 */

Overload Comments

A function overload comment should appear before and after the overloaded functions. The comment should be the same as the function name. Ex:

// \/ MyFunction \/ //

void MyFunction(float Param1, bool bParam2);
void MyFunction(FVector Param3);

// /\ MyFunction  /\ //

Long Line Comments

A brief code description should appear over any line of code longer than the screen at 100% zoom or when it seems helpful. Descriptions should be complete sentences.

// [Briefly explain the logic]
MyVar = bMyBool ? MyOtherVar - (MyVar * MyVar).MyFunction(MyOtherOtherVar) : FMath::Max(MyOtherVar, 0.f);

Complex Getter Comments

Any large complicated segment of code obtaining a single value inside a chunk of logic should either be commented. Sentence case should be used. Ex:

//         |-------------------------------------- Get a variable ----------------------------------| + |-------- Get other function info --------| 
MyFunction(Cast<AGameModeClass>(UGameplayStatstics::GetGameMode())->GetAnActor()->GetAFloatVariable() + AObjectVariable->MyOtherFunction(AVarable));

or

float GetAVariable = Cast<AGameModeClass>(UGameplayStatstics::GetGameMode())->GetAnActor()->GetAFloatVariable();
float GetOtherFunctionInfo = AObjectVariable->MyOtherFunction(AVarable);
MyFunction(GetAVariable + GetOtherFunctionInfo);

Logic Chunk Comment

Any block of code working on a single thing that is longer than around half the screen should have a comment explaining what the code is doing. Sentence case should be used.

// \/ [Code description - Should be brief] \/ /

[Code]
[More code]
[Even more code]

// /\ [Code description] /\ /