• Looking at the example scripts above, you can see the order of declarations followed:
  • Class declaration
  • Variables declaration
  • Methods declaration
  • Updating events declaration
    • these are chronological (example: Awake, Start, then Update)

• There are two types of comments, each for a different purpose:
  • '//'
    • used for description
    • enclosed differently, depending on its location:
      • '// encloses either end of the description when inline //'
      • 'public int mineralsRemaining; // encloses only left side of the description when sideline'
  • '/**/'
    • used for: disabling debug messages, archiving older code that you aren't ready to delete yet, or filling in pseudocode for planning purposes
      • having these kinds of comments handled differently implies to the programmer that it demands their attention
      • this kind of comment was chosen for this purpose, instead of the '//' kind, because it can be used between any two points in code instead of having to apply the '//' to each line in question
      • examples:
        • '/*print(name+" suffers "+damageDealt+" damage!")*/'
        • '/* have the goblin jump here */'

Name classes briefly

To make class names easier to read and type, use single-word nouns whenever possible. For example, try 'Gun' instead of 'ProjectileShooter'.

This requires a bit of creativity sometimes, to create new words or even new meanings for words that already exist. For example, using 'Doodad' instead of 'InteractiveButInertToy'. The point is to come up with a one-worder that encompasses the nuances of the type of thing you are coding, so you can pack as much meaning in one word as possible.

This way, scripts for specific characteristics of such nouns will be much more straightforward to read and type, in turn. For example, 'DoodadSpawner' instead of 'InteractiveButInertToySpawner'.

In the 'InteractiveButInertToy' example, simply using 'Toy' won't cut it, because there are other Toys in the game, such as Units. Coming up with your one-worder is well worth it, once you get everyone else on board with your new definition.

Name classes diegetically

Whenever possible, the name should describe a characteristic of the object it will be applied to, instead of an arbitrary happening which could be interpreted out of context. For instance, say a book is used to "imagine" different scenes in your game. You could give the book object a script called 'BookImagining', as opposed to 'SceneManager'. This tells developers that the script is used by the book. We know where to find it and where to put it. It also doesn't imply that there is some additional 'Scene Manager' or similarly named object, which would be unnecessary clutter. Certainly there is no reason to create a 'Scene Manager' object which tracks its position, rotation, and scale in the world space yet does not tangibly exist.

Name extending classes as revisions of the parent

For example, use the name 'GoblinGoonBehavior' for a script that extends a script called 'UnitBehavior', but don't use the name 'GoblinGoonBrain' to extend from 'UnitBehavior'. In this way, you know intuitively that the 'GoblinGoonBehavior' script extends the 'UnitBehavior' script, because of the common word 'Behavior'.

Furthermore, if a 'Goblin Goon' is a particular kind of 'Unit', according to the design of the project, then that fact requires you to use the name 'GoblinGoonBehavior' instead of 'GoblinGoonUnitBehavior' (which would be redundant).

If the parent class is ever really long, then it may be impractical to include its name in the name of the extending class; there is a point at which brief naming must take precedence over this rule, which is up to the programmer's discretion.

Use 'CamelCase'

• This is a Unity standard and it is thusly superior for us because Unity will properly space out the name in the inspector, for example, from 'ClassName' to 'Class Name'. Be sure to capitalize the beginning of the class name, to differentiate it from variables and methods; name like 'ClassName' as opposed to 'className'.
• Bonus: Use the Subword Navigation extension for Visual Studio to efficiently navigate through subwords in 'camelCaseVariableNames' instead of spamming arrow keys or using your mouse. This wouldn't be very practical with 'snake_case', to name an alternative, because of the underscore character preventing your cursor from having a middlepoint between subwords.

Procedure

• Try to comment classes in just one line if they are simple enough. For example, a 'FanSpinner' class's description could read: 'constantly spins this fan'.
• Otherwise (if you have to describe the class using multiple lines), be sure to do a bullet-pointed breakdown.

Keep in mind that one doesn't need to understand the granular workings of the class, just the general idea of what purposes it achieves. Let the code commenting within speak for itself to explain the details of the operations involved to achieve the purposes of the class.

• Brackets should be done by the common C# convention, where opening brackets are newlined.
  • This makes scope easier to read once multiple bracketed blocks of code become nested.

The purpose of this style aspect is to separate purposefully-distinct sections of code, as well as their corresponding comments, in order to discretize concepts for optimized legibility.

Line spacing

• If multiple consecutive lines are on the same level of abstraction and purpose, just don't put empty lines between them.
• If multiple consecutive lines achieve different goals, put an empty line between them to spread things out for visual clarity.
• If multiple groups of consecutive lines achieve different, higher-level goals, put two empty lines between them to spread things out for visual clarity. For example:

• As more concept scopes (levels of abstraction) are added, they will require further distinction. The line spacing pattern continues, increasing in powers of two from 1, to 2, to 4, to 8, and so on, because increasing line spacing along powers of two is more visually obvious than linearly-increasing line spacing.

Comment positioning

• Comments made inline (at the same indentation of that scope of code) describe everything coded until either the next inline comment, or the section ends (according to either line spacing or parent brackets).
• Comments made sideline (on the side of a line) describe the code on the corresponding line.

• Lines of code should be commented to describe what they are doing – this is more important as more scope changes occur in the lines of code.
• See the above section on 'Comment positioning' to infer how to include line comments.

• Variables should be private by default; only make them public if necessary.
  • Private methods are for helping out within the class.
  • Public methods are for providing something to the inspector, another class, or both.
• Variables can be made static to remain generic to the class; for example, a class setting such as an attack radius generic to all Footmen.
• Variable Typing influences Variable Type Commenting, as explained below.

• Use 'camelCase'. This is a Unity standard and it is thusly superior for us because Unity will convert such camel case variables in the inspector to sentence case: 'goblinGoon' becomes 'Goblin Goon'.
• Start with lowercase, not uppercase: 'goblinGoon', not 'GoblinGoon'.
• When you find multiple variables used in parallel, such as 'greenGoblin' and 'blueGoblin', to become hard to distinguish, change the adjectives from prefixes to suffixes, like so: 'goblinGreen', 'goblinBlue'.

Purpose

A variable is notated as having a certain type in order to easily recognize the use case of the variable.

For starters, a public variable is considered a "setting" because in Unity, public variables can be "set" in the inspector, by default. Here are some settings shown in the inspector:

A setting can be either local or global.

Local settings are those that show in the inspector local to a particular instance of a script.

Global settings are another category of setting, which apply for all instances of the class. They must be set within the code where they are declared. As such, they cannot be shown locally in the inspector. They can even be private, instead of public, as a result. When they are public, however, they are considered to be provided because they are intentionally being "provided" to other classes.

Another category of variable types is trackings. Trackings are simply variables keeping track of something. Unlike settings, they are intended to change over time as methods update them, instead of being set before the game starts. Trackings can either be private, settable, or provided, much like global settings, depending on whether they should be made available to other classes or if they are allowed to be set initially in the inspector like one would set a setting.

Connections are the final category of variable types. They are references made to other classes within the Unity environment. Manual connections are shown in the inspector, much like settings, whereas automatic connections are hidden, to be "automatically" connected to in the code, often in either the Awake or Start events.

Types of variables are categorized by:

• settings, which can be:
  • local
  • global, which can be:
    • private
    • provided
• trackings, which can be:
  • private
  • settable
  • provided
• connections, which can be:
  • manual
  • automatic

Typing for each category is coded as follows:

• setting - local: 'public'
• setting - global - private: 'private static'
• setting - global - provided: 'public static'
• tracking - private: 'private'
• tracking - settable: 'public'
• tracking - provided: '[HideInInspector] public'
• connection - manual: 'public'
• connection - automatic: 'private'

• Before commenting to describe a variable, declare its type (per the above style aspect), followed by a colon then leading into the description.
  • For example: 'setting: cooldown duration'.
• For parallel-purpose variables, such as 'damageMin' and 'damageMax', they can be declared on the same line and as such be commented together.
  • For example: 'settings: min and max damage values'.

• Methods should be private by default; only make them public if necessary.
  • Private methods are for helping out within the class.
  • Public methods are for providing something to another class.
• Methods can be made static to support calls generic to the class; for example, a function to change a class setting such as an attack radius generic to all Footmen.

• Use 'camelCase'. This is a Unity standard and it is thusly superior for us because Unity expects this in some places throughout the editor. Furthermore, it allows the brief and therefore efficient '_' (underscore) to be used to denote an easily recognizable distinction, which would otherwise be difficult to recognize among the underscores of 'snake_case'. (See the relevant point below in this section for the usage of '_'.)
• Use post-adjectives to differentiate when multiple methods start to become confused: 'spinX()', 'spinY()' instead of 'xSpin()', 'ySpin()'.
• Custom methods should begin in lowercase, as in 'customMethodName()', not uppercase, as in 'CustomMethodName()'; this serves to differentiate custom methods from Unity-provided methods (which follow the capitalization pattern of 'UnityMethodName()'). This does not clash with variable nomenclature, because methods must uniquely end with parentheses, as in 'methodName()', not 'methodName'.
• Because C# overloading is not supported between static and instanced (nonstatic) versions of the same method, in order to distinguish such methods as minimally as possible use a '_' suffix at the end of the instanced method, like so:
  • static method: 'toggleMidairJumping()'
  • instanced method: 'toggleMidairJumping_()'

• Method comments first declare the method's type, then that is followed by a colon, then a description of the method, sometimes followed by a parenthetical description containing more granular detail.
  • Here are some examples:
    • '// method - private: determine damage range for a melee attack //'
    • '// method - provided: calculate the smell of this object apparent to other objects (by measuring its stink relative to the max stink value)'

These events are quite self-explanatory; however, it can help to comment as shown in the script made for example.