Don't You Hate It When You Wait for the Build Only to Find...

Missing editor settings... or missing components that a script needs... or a missing game object that provides a central control for the game...

But writing all that defensive code in the script gets repetitive. Writing if this is null in Start() and checking that a prefab was set in the public fields of a component. It's the kind of code that adds little value and shouldn't _have_ to be there... but people are people and mobile builds take forever. Forget a setting in the editor and a build is trash.

If Only Defensive Code Were Cleaner

Clean Code is a book written by Robert Martin and it points out some very useful approaches for writing maintainable code. In Melbourne, Australia, many companies hiring software developers demand skills for producing clean code. The results speak for themselves. Defensive code can clutter up a code base and gets pretty noisy, so how to do both?

As I sit here developing for Yubric Reality, I found ways to keep the defensive code simple. I'm sharing that code and other helpful Unity Component bits-n-pieces in a GitHub project called UnityComponents - a really imaginative name - I know....

https://github.com/WazzaMo/UnityComponents

The project has a namespace called Tools.Common and this has a number of new utility classes. The first one I'll describe is the MonoBehaviourExt that contains extension methods for a MonoBehaviour.

In the examples below, the methods will log (as warning) if the required component reference or editor parameter was not configured correctly in the editor. This log will appear in the Android Monitor, the iOS debug output or in the Editor Console with the prefix of "Unity >" so it is easy to find and filter on.

Checking if MonoBehaviour Fields are Null

Somethings are easier tweaked in the editor so you make public fields (or private with the [SerializeField] attribute) and initialise them to null with the idea that the scene in the editor will set the value. You could check if each were non-null at Start() or Awake() and log errors for each that are, or you can do this.

This will log a warning with the name of the variable that is not configured. Note: It uses reflection to determine the missing variable(s) which may or may not work with ILCPP code but you should get a warning at least.

Most of these extension methods also have a variant that use a control variable so you can disable the Update() method if the object is not configured.

Getting Component References Safely

A common thing in a script is to get a reference to another component on the same GameObject but the human designing the scene may have forgotten to add the necessary component. Sure you can use the [RequireComponent] attribute but this also tends to forcibly add the component without any configuration just forcing the problem along. A better solution is to use another extension method.

See how clean that was! Errors don't become exceptions, they become warnings and a quick Play in the Editor will reveal most issues in the scene before we try a build. Methods are short and sweet and the intention is very clear.

Wrapping Up

This little intro into using the UnityComponents extension methods is just a tip in the iceberg. I hope you found it interesting and useful.