Naming

The following naming conventions are designed to provide a clean and consistent public API and to provide additional clarity of purpose and scope for variables.

Token Capitalisation Reason
namespace
class
struct
interface
enum
delegate
Method
PascalCase Looks clean and easy to read.
Property
const Field
readonly Field
event
PascalCase They cleanly control how things can be accessed so users of the public API can be confident that any behaviour exposed to them is intentional and can be used safely (unlike directly regular fields which can't validate the values assigned to them).
Non public Field _PascalCase Not meant to be externally visible (users should never see an underscore) but still has a wider scope than most other variables depending on the actual access modifier.
public Field camelCase Is externally visible and can be get/set very efficiently and without immediate side effects, unlike a property which can run potentially expensive calculations or trigger any other code when set.
Parameter camelCase Similar to a public field, but within a smaller scope.
Local Variable camelCase Similar to a parameter, but within a smaller scope.
Preprocessor Directive MACRO_CASE Only used by the compiler, which is very different from regular code that gets executed as the program runs. Also, any ! symbol should have a space between it and the target since that character is easy to miss among upper case letters, e.g. #if ! UNITY_EDITOR.

File Naming

  • Script file names should match the main type they contain. This is mandatory for anything inheriting from UnityEngine.Object, but is also a good practice in general.
  • When using a partial type to declare a nested type in a separate file from the main script, the script should be named in the same way it would appear when accessing the nested type externally, i.e. OuterType.InnerType.cs.
  • If a generic type shares the same name as a non-generic type, the generic file should have a T suffix, i.e. TypeNameT.cs.
  • If multiple generic classes share the same name, their file names should have a numerical suffix indicating the number of generic parameters they have, e.g.
    • StateMachine<TState> is in StateMachine1.cs.
    • StateMachine<TKey, TState> is in StateMachine2.cs.