Type Coding Standards

General Rules

• Avoid Nested Typedefs - Nested typedefs i.e. a typedef of a typedef should be avoided if possible. They make code extremely hard to read.
• UObject Inheritance - Classes should almost always derive from UObject as this allows for Unreal to handle garbage collection and allows the class to interface with the editor, blueprints, and many other features.
• Use Forward Declarations - In a .h file always use a forward declaration when possible. This improves compile times and reduces dependencies.
• Minimise Includes - If it is possible to make it so that a type does not require an include of another, then do so. Large numbers of includes are often a sign of spaghetti code and broken encapsulation.
• Be Careful of Typedefs and Templates - Both typedefs and templates can be very useful when coding; however, neither is supported by much of the Unreal editor interface. They cannot be seen in the editor and aren't supported by delegates.
• Enum Declaration - Enums should be declared as classes deriving from uint8. This eliminates the need for TEnumAsByte and makes some math easier. Ex:

class enum EMyEnum : uint8
{
   [Entries]
}

Naming

Type names should always be singular nouns in pascal case and are prefixed by one of the following:

• Template classes are prefixed by T.
• Classes that inherit from UObject are prefixed by U.
• Classes that inherit from AActor are prefixed by A.
• Classes that inherit from SWidget are prefixed by S.
• Classes that are abstract interfaces are prefixed by I.
• Enums are prefixed by E.
• Delegate names should end with Delegate and be prefixed by F.
• Everything else should be prefixed by F.
• Typedef names should end with Type and be prefixed by whatever their type is prefixed by i.e. typedef FVector FMyLocationType.

Commenting

Decription

A type comment should appear before the definition. Descriptions should be complete sentences.

• Class comments should describe what the class represents and what it can do.
• Struct comments should describe what is stored by the struct and any special functionality it has.
• Enum comments should describe what state it represents.
• Typedef comments should describe how the type is used.
• Delegate comments should describe what information is broadcast by that type.

/*
 * [Type description]
 */

Type Marker

A type name comment should appear before and after the class definition (in the .h) and before and after the definitions of the class's functions (in the .cpp). The type name should be used as the comment. Ex:

/* \/ ========= \/ *\
|  \/ UMyClass  \/  |
\* \/ ========= \/ */

class VOIDSINGER_API UMyClass : UObject
{
    GENERATED_BODY()

    [Code]
};

/* /\ ======== /\ *\
|  /\ UMyClass /\  |
\* /\ ======== /\ */

Functionality Category Markers

Category comments should appear before and after groups of functions and variables that all relate to a similar piece of functionality. These category markers should appear in both the .h and the .cpp. An example could be Voidsong Input Management. If in the .h, a new access specifier should always be placed after a new category starts, and members should be organized such that public comes first and then protected then private. In general, functions should appear before variables. Title case should always be used in category comments.

The Category specifier of UFUNCTIONs and UPROPERTYs should match these categories. Ex:

   /* ----------------- *\     
   \* \/ My Category \/ */  

public:

   UFUNCTION(BlueprintCallable, Category="My Category|My Subcategory")
   void MyFirstFunction();

   UPROPERTY(BlueprintReadWrite, Category="My Category")
   int MyFirstVar{ 0 };
                
protected:

   UFUNCTION()
   float MySecondFunction();

   UPROPERTY(BlueprintReadOnly, Category="My Category|My Subcategory")
   UObject* MySecondVar{ 0 };

private:

   UPROPERTY()
   bool bMyThirdVar{ 0 };

   /* /\ My Category /\ *\     
   \* ----------------- */