📄

Code Naming Convention

Code Naming Convention

  • Rather than simply answering "what" or "how," comments can fill in the gaps and tell us "why."
  • Use the // comment to keep the explanation next to the logic.
  • Use a Tooltip instead of a comment for serialized fields.
  • Avoid Regions. They encourage large class sizes. Collapsed code is more difficult to read.
  • Use a link to an external reference for legal information or licensing to save space.
  • Use a summary XML tag in front of public methods or functions for output documentation/Intellisense.
  • Rather than simply answering "what" or "how," comments can fill in the gaps and tell us "why."
  • Use the // comment to keep the explanation next to the logic.
  • Use a Tooltip instead of a comment for serialized fields.
  • Avoid Regions. They encourage large class sizes. Collapsed code is more difficult to read.
  • Use a link to an external reference for legal information or licensing to save space.
  • Use a summary XML tag in front of public methods or functions for output documentation/Intellisense.

Naming/Casing

  • Use Pascal case (e.g. ExamplePlayerController, MaxHealth, etc.) unless noted otherwise
  • Use camel case (e.g. examplePlayerController, maxHealth, etc.) for local/private variables, parameters.
  • Avoid snake_case, kebab-case, Hungarian notation

Formatting

  • Choose K&R (opening curly braces on same line) or Allman (opening curly braces on a new line) style braces.
  • Keep lines short. Consider horizontal whitespace. Define a standard line width in your style guide (80-120 characters).
  • Use a single space before flow control conditions, e.g. while (x == y)
  • Avoid spaces inside brackets, e.g. x = dataArray[index]
  • Use a single space after a comma between function arguments.
  • Don’t add a space after the parenthesis and function arguments, e.g. CollectItem(myObject, 0);
  • Don’t use spaces between a function name and parenthesis, e.g. DropPowerUp(myPrefab, 0);
  • Use vertical spacing (extra blank line) for visual separation.

Comments

  • Rather than simply answering "what" or "how," comments can fill in the gaps and tell us "why."
  • Use the // comment to keep the explanation next to the logic.
  • Use a Tooltip instead of a comment for serialized fields.
  • Avoid Regions. They encourage large class sizes. Collapsed code is more difficult to read.
  • Use a link to an external reference for legal information or licensing to save space.
  • Use a summary XML tag in front of public methods or functions for output documentation/Intellisense.

Namespace

  • Pascal case, without special symbols or underscores.
  • Add using line at the top to avoid typing namespace repeatedly.\
  • Create sub-namespaces with the dot (.) operator, e.g. MyApplication.GameFlow, MyApplication.AI, etc.
namespace Gamepangin.StyleExample { }

Enums

  • Use a singular type name.
  • No prefix or suffix.
public enum Direction
{
North,
South,
East,
West
}

Flags Enums

  • Use a plural type name
  • No prefix or suffix.
  • Use column-alignment for binary values
[Flags]
public enum AttackModes
{
// Decimal // Binary
None = 0, // 000000
Melee = 1, // 000001
Ranged = 2, // 000010
Special = 4, // 000100
​
MeleeAndSpecial = Melee | Special // 000101
}

Interfaces

  • Name interfaces with adjective phrases.
  • Use the 'I' prefix.
public interface IDamageable
{
string DamageTypeName { get; }
float DamageValue { get; }
​
// METHODS:
// - Start a methods name with a verbs or verb phrases to show an action.
// - Parameter names are camelCase.
bool ApplyDamage(string description, float damage, int numberOfHits);
}
​
public interface IDamageable<T>
{
void Damage(T damageTaken);
}

Classes / Structs

  • Name them with nouns or noun phrases.
  • Avoid prefixes.
public class StyleExample : MonoBehaviour { }

Fields

  • Avoid special characters (backslashes, symbols, Unicode characters); these can interfere with command line tools.
  • Use nouns for names, but prefix booleans with a verb.
  • Use meaningful names. Make names searchable and pronounceable. Don’t abbreviate (unless it’s math).
  • Use camelCase.
  • Add an optional underscore () in front of private fields to differentiate from local variables
  • You can alternatively use more explicit prefixes: m = member variable, s_ = static, k_ = const
  • Specify (or omit) the default access modifier; just be consistent with your style guide.
public bool canJump;
private int elapsedTimeInDays;
​
// Use [SerializeField] attribute if you want to display a private field in Inspector.
// Booleans ask a question that can be answered true or false.
[SerializeField] private bool isPlayerDead;

Properties

  • Preferable to a public field.
  • PascalCase, without special characters.
  • Use the expression-bodied properties to shorten, but choose your preferred format. e.g. use expression-bodied for read-only properties but { get; set; } for everything else.
  • Use the Auto-Implemented Property for a public property without a backing field.
// the private backing field
private int maxHealth;
​
// read-only, returns backing field
public int MaxHealthReadOnly => maxHealth;
​
// equivalent to:
// public int MaxHealth { get; private set; }
​
// explicitly implementing getter and setter
public int MaxHealth
{
get => maxHealth;
set => maxHealth = value;
}
​
// write-only (not using backing field)
public int Health { private get; set; }
​
// write-only, without an explicit setter
public void SetMaxHealth(int newMaxValue) => maxHealth = newMaxValue;
​
// auto-implemented property without backing field
public string DescriptionName { get; set; } = "Fireball";

Events

  • Name with a verb phrase.
  • Present participle means "before" and past participle mean "after."
  • Use System.Action delegate for most events (can take 0 to 16 parameters).
  • Define a custom EventArg only if necessary (either System.EventArgs or a custom struct). OR alternatively, use the System.EventHandler; choose one and apply consistently.
  • Choose a naming scheme for events, event handling methods (subscriber/observer), and event raising methods (publisher/subject) e.g. event/action = "OpeningDoor", event raising method = "OnDoorOpened", event handling method = "MySubject_DoorOpened"

Methods

  • Start a methods name with a verbs or verb phrases to show an action.
  • Parameter names are camel case.
Last modified 14d ago