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 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 TEnumeAsByte and makes some math easier. Ex:

class enum EMyEnum : uint8
{
   [Entries]
}

Naming

Type names should always be 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 class comment should appear before the class definition. Descriptions should be complete sentences.

/*
 * [Class description - Should explain what this is, what it does, and what it stores]
 */

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. Title case should always be used in category comments.

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

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

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

   UFUNCTION(BlueprintCallable, Category="My Category|My Subcategory")
   void MyFirstFunction();
                
protected:
   UPROPERTY(BlueprintReadOnly, Category="My Category|My Subcategory")
   UObject* MySecondVar{ 0 };

   UFUNCTION()
   float MySecondFunction();

private:
   UPROPERTY()
   bool bMyThirdVar{ 0 };

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

Delegate comments should appear above their definition.

//[Description - Explain what information is broadcasted]

Typedef comments should appear above their definition.

///[Description - Explain what kind of information is stored by this type]