Default Script Template

When you create a new script, Unity uses a text file to specify its initial layout. That text file is located in your Unity installation folder:

  • Windows: C:\Program Files\Unity\Editor\Data\Resources\ScriptTemplates
  • Mac: /Applications/Unity/Unity.app/Contents/Resources/ScriptTemplates

These paths may differ if you are using Unity Hub or chose a different path when installing Unity.

The template for a new C# Script is 81-C# Script-NewBehaviourScript.cs.txt.

If you make changes to any of the templates, you should keep a copy of your changed file somewhere else so that you do not lose it if you uninstall Unity and can easily apply it when you install a new version of Unity.

It is recommended that you remove the default Start and Update methods because they have a performance cost just for existing, even if they are empty. Adding them back in when you actually need them only takes a few seconds and this helps encourage you to keep your scripts clean. At the very least, you should remove their comments which are absolutely useless to the extent that lazy people who leave them in often do not even bother changing them when they rename the method, meaning the comments become worse than useless because they are not even correct about what the method does anymore.

Any other modifications are up to you. The template used by Kybernetik looks like this:

using System;
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using Object = UnityEngine.Object;

public sealed class #SCRIPTNAME# : MonoBehaviour
{
    /************************************************************************************************************************/

    /************************************************************************************************************************/
}

Note that the /**** is actually on the line immediately after the { and indented, it just looks like there's an extra line between due to word wrapping.

Why using Object = UnityEngine.Object;?

  • In C#, every type (class, struct, interface, etc.) inherits from System.Object.
  • Unity also has a UnityEngine.Object class which many things inherit from, including components, game objects, and all asset types.
  • Since both classes are called Object, a script containing both using System; and using UnityEngine; must always specify the namespace when using an Object variable.
  • The using Object = UnityEngine.Object; statement is essentially saying "unless specified otherwise, an Object is always a UnityEngine.Object" since that type is used much more commonly in Unity scripts. This is known as an alias.
  • If we do want to use the System.Object type, we can always use the object keyword (lowercase o) which is built into the C# language just like the int keyword is simply an alias for System.Int32.

Why sealed?

  • By default, any class in C# can be Inherited.
  • This is often problematic since a class that was not designed to be Inherited may behave unexpectedly.
  • The sealed keyword indicates that the class cannot be Inherited.
  • Having everything sealed by default is much safer. If you want to Inherit from a sealed class, you can simply remove that keyword. When doing so, it is worth having a quick look over the class to see if there is anything that should be made protected and/or virtual.
    • In particular, MonoBehaviour event methods like Awake, OnEnable, etc. should generally have both of those keywords in a class that can be inherited. They do not need to be public for Unity to call them and your other scripts do not generally need to call them either. But if you have a private method in the base class, you can put another method with the same name in the child class without ever noticing and Unity will only call the child method, which often results in a bug. So by changing them to protected virtual when you remove the sealed keyword you ensure that you get compiler warnings immediately if the child class tries to use the same method without overriding it correctly.

Why /*************...?

  • These are Comment Separators which help to improve code readability as explained by the Coding Standard.