Several times throughout the course, we learn how to add a namespace before we try to use different Types, like UnityUI or TextMexhPro. While it is good to know that we need to do this, we won’t always know WHAT namespace to add before hand. You might be thinking, “How DO I know what namespace’s I might need to use?”
Well, without having to dig through the Unity Docs to see what namespace we need, we can let Visual Studio do it for us.
Typically, when you type in a variable Type, Visual Studio will automatically ADD the using directive need for it to function. So if you type in TextMeshProUGUI, Visual Studio will add the using TMPro namespace.
Even if you find that you get the red sguiggly lines because VS did not add the namespace automatically, you can right click the variable Type or press ctrl+., to bring up Quick Actions and Refactoring menu and it will have at the top of the suggestions list, to add the required namespace.
Below is an example of Visual Studios Quick Actions and Refactoring menu with “using TMPro” as the first suggestion. Note, I had to delete the using directive first, because my version of VS automatically added the using TMPro namespace when I used intellsense to autocompletTextMeshProUGUI.
Which brings us to a bonus question. Why not just have all the namespaces accessible by default?
Now technically we DO have access to all of them at our fingertips. Instead of adding using TMPro, we can change TextMeshProUGUI to TMPro.TextMeshProUGUI. We included the namespace as part of the Type. But now Imagine we had a lot of TextMeshProUGUI Types in our code, that’s a lot of extra typing we have to do. But by adding using TMPro, we avoid having to append the namespace each time.
You can delete using UnityEngine, and [UnityEngine.SerializeField] is becomes a valid line of code, but [SerializeField] will now throw an error. But who wants to type UnityEngine. before every method or type that needs that namespace?
There is a lot more to namespaces and why we use them (organization and Type naming collisions are the two biggest).
Real World example: When doing the Number Wizard course, as part of the code I added to display the history of previous guesses, I used Enviroment.NewLine as part of a string.Join function. Here is the problem, Enviroment.NewLine is part of the System namespace, which VS added automatically. The System namespace also has a Random Type, just like UnityEngine. After adding Enviroment.NewLine (and thus adding using System), I got an error stating that Visual studio no longer knew what Random I was referring too, System.Random, or UnityEngine.Random. This is a namespace collision. The easy fix for this was to delete Using System and change Enviroment.NewLine to System.Enviroment.NewLine. With using System no longer in the code, the compiler would not try to look inside of it, see it has a Random type, and get confused.