Code Naming Conventions

Naming conventions should be treated as law. A project that conforms to a naming convention is able to have its assets managed, searched, parsed, and maintained with incredible ease.

Examples

name		convention
class name		should start with uppercase letter, be 1 noun with optional adjective and imply its purpose e.g. Minigame, SingingFrogs etc.
interface name		should start with uppercase letter and be an adjective e.g. Runnable, Remote, ActionListener etc.
method name		should start with uppercase letter and be a verb e.g. ActionPerformed(), Main(), Print(), Println() etc.
variable name		should start with lowercase letter e.g. firstName, orderNumber etc.
constants name		should be in uppercase e.g. RED, YELLOW, MAX_PRIORITY etc.

• Reveal intentions: fileName is better f; maxPugs is better than pugs.

• Make distinctions: moneyInDollars is better than money.

• Put the distinguishing aspect first: dollarMoney and rupeeMoney are better than moneyInDollars and moneyInRupees.

• Easy to pronounce: timeStamp is better than ts.

• Verbs for functions: GetName() and IsPosted() are good; HasWeight() or IsMale() when boolean values are returned; ToDollars() for conversions.

• One word, one concept: fetch, retrieve, get all imply the same thing: use one of them consistently.

• Relate to business context: AddCustomer is better than IncrementCounter.

• Use shortforms judiciously: PremiumCust may be used over PremiumCustomer to emphasize "Premium"; but fn is not a good substitute for fileName.

• Describe content and storage: userInfoList is better than userInfo.

• Plurals for containers: fruitNames is better than fruit for an array of fruit names.

• Describe content rather than presentational aspects: in CSS, for example, main-section is better than middle-left-and-then-a-little-lower as identifier name.

• Use Camel case: First letter of every word is lowercase (above convention still apply, so classes still start with a uppercase) with no spaces or symbols between words. Examples: userAccount, fedEx, wordPerfect.

• Public variables should use PascalCase.

• Private variables should use _camelCase.

• Serialized private variables (using [SerializeField]) should use camelCase.

• UnityEvents should use PascalCase and start with "On".

Scripting Templates

To save some time you can overwrite Unity's default script template with your own to automatically setup the namespace and regions etc. See this Unity article to learn how.

Namespace

To avoid conflicts with existing classes, enums, interfaces, and other elements from different namespaces or the global namespace, it is important to utilize namespaces. By using namespaces, you can ensure proper scoping and prevent clashes. It is recommended to name the namespace after your project to minimize conflicts with any imported third-party assets. Additionally, it is good practice to provide a summary for all public functions. Essentially, any function with a public access modifier should have its summary accurately documented.

Class Organization

When structuring classes, it's crucial to prioritize the convenience of the reader over the writer. Since most readers will interact with the public interface of the class, it's recommended to have only one public type per source file, while allowing multiple internal classes. It is also best practice to name the source file after the public class it contains.

To maintain a clear and organized structure within namespaces, follow these guidelines:

Arrange class members in an alphabetical order, grouped into relevant sections:

• Constant Fields.
• Static Fields.
• Fields.
• Constructors.
• Properties.
• Events / Delegates.
• LifeCycle Methods (such as Awake, OnEnable, OnDisable, OnDestroy).
• Public Methods.
• Private Methods.
• Nested types.

Within each group, order the members based on their access level:

• Public.
• Serialized Fields.
• Internal.
• Protected.
• Private.

However, there is an exception to this order. Serialized or public UnityEvent should always be declared under everything else. This exception ensures a more organized appearance in the inspector.

By adhering to these practices, you can enhance the readability and maintainability of your code for anyone who interacts with it.

V.A.L

In C#, variables possess an access level that determines their accessibility. A public variable can be accessed by any code outside the class. A protected variable can only be accessed by the class itself and any child classes. On the other hand, a private variable is accessible only within the class itself, without any access granted to child classes. It is important to limit the use of public variables and instead consider making them private or protected whenever possible.

To expose variables for serialization in Unity, it is preferred to use the attribute [SerializeField] instead of directly making the variable public. This allows for more controlled and explicit access while still enabling serialization.

For local variables within methods or functions, it is recommended to use camelCase for naming conventions. This ensures consistency and readability within the codebase.

By following these guidelines, you can enhance encapsulation, control variable access, and improve code readability and maintainability.

Compile

To maintain a high-quality codebase, it is crucial to ensure that all scripts compile with the least amount of warnings and zero errors. Promptly addressing script warnings and errors is essential as they can quickly lead to unexpected and potentially problematic behavior. It is important not to submit broken scripts to source control. Instead, if you need to store them in source control, consider shelving or stashing them temporarily.

By diligently fixing warnings and errors, you contribute to a more stable and reliable codebase. It is recommended to regularly monitor and address any issues that arise during the development process to prevent the accumulation of technical debt and potential complications down the line.

Comments

When it comes to commenting, it is essential to provide clear and informative explanations. Comments should be used to describe the intention, algorithmic overview, and logical flow of the code. The goal is for someone other than the author to be able to understand the intended behavior and general operation of a function just by reading the comments.

While there are no specific minimum requirements for comments, it is encouraged to include comments that reflect the programmer's intent and approach for most routines. Even though very small routines may not require comments, it is hoped that the majority of routines will have comments to provide insights into the programmer's thought process and implementation approach.

By adding well-considered comments, you enhance the comprehensibility and maintainability of your code, enabling other developers to understand your code more easily and effectively.