Unity Concepts: Dealing with Console WarningsPosted by on


If you have ever imported an asset you have likely seen already a compiler warning or two during your usage of Unity.   Console warnings are so at home in unity they have their own dedicated window.  A lot of times they are bothersome.

If you have found this article and share questions such as “How do we only show errors that actually matter?” or “How can we distinguish warnings that have no impact and occur from valid code?”.  You in luck as that’s exactly whats in store.

In this article we are going to take a closer look at these console warnings and learn how to deal with them in a variety of ways.   Hopefully at the end of the article you will once again see them as valid communication from the compiler and now a waste of time to read through so many warnings, not knowing if they are actual errors or worse yet, knowing they are coming from completely valid code.

AresTheDog Studio Paw Logo

Compiler Warnings

Compiler warnings are important.  They mean that the compiler has checked your code and even though everything will run and compile there are things you need to be aware of.  The compiler isn’t saying there is going to be a problem, if it was, it would be in red and be an Error not a warning. The Unity Editor has a dedicate window for the console and it’s warnings among it’s other uses.   When it comes to compiler warnings they are inevitable and when you find yourself using Unity and Assets they are abundant enough and appear in such numbers that they have likely lost all meaning.   One merely needs to open a few assets to experience the bombardment of console warnings.

Sometimes they point out code that is actually wrong or going to have bad results, other times they let you know about unused values or obsolete and deprecated code.   They are the bane of Unity Assets.   They go foreth and multiply and with ever version ever more fruitful.   Let’s face it, after a while of using Unity and various assets they end up becoming some sort of annoying background noise whenever you import a new asset.

This doesn’t mean that the assets are broken or will not work.  Most of the time they are perfectly fine.   Most of the time it’s the fault of using a different version of Unity then what the asset had been released for.   Even so, we all can agree that sometimes these warnings can be annoying and worse still,  it’s just the compiler complaining about the way you wrote perfectly valid code that contains no actual bugs.

Remember, Warnings are there to alert programmers. 

There will come a time, after many thousands of warning there will be one that actually matters and we should pay attention too.   We can tell you throughout are experience that we have written code that did not perform the way we intended and had done something “bug” worthy.   It’s those time’s we learn to appreciate the compiler warnings.

“A warning is not exactly a ‘warn you about potential bugs’ feature. It’s the compiler (a language interpreter) telling you that you have abused the language in some way.  Like a French guy telling an American who tried to speak French, ‘Your French is terrible, but I managed to get what you are saying anyway.’ — Bill MacDonold, Software Architect at GoPro, Inc.

You can learn some interesting and unexpected behavior of any programming language you’re learning from the compiler warnings.  Warnings in the UnityEditor can teach you a lot just from the warning.  Warnings in the UnityEditor do not halt the execution of the project, they merely display the specified warning message in the console window.   When it comes to these warnings we can  actually decide on if we want to disable them and prevent them from being seen.

Compiler Warning Facts

    • Fact: the vast majority of warnings are not bugs, and will never cause bugs, problems or issues.
    • Fact: An extremely small percentage of warnings are or will cause bugs.
    • Fact: An even smaller percentage of warnings are catastrophic. As a bug where people might die, corporations or economies might collapse, people could lose their jobs.
  • Fact: A small percentage of warnings are just due to how you wrote something, but trying to fix then is risk that you might cause bugs.

Console Warnings

Let’s take a look at a C# script for Unity that will display some of the most common warnings that appear.

using UnityEngine; 
public class ConsoleWarnings : MonoBehaviour 
{
    private int Health = 10;
    private float Stamina = 10f;
    private string Name = "Player";
    public void EmptyMethod (int number)
    {
         if (number > 5);
         else
         {
             UnityEngine.Application.LoadLevel(1);
         }     
    UnityEngine.LineRenderer lineRenderer = new UnityEngine.LineRenderer();     
    lineRenderer.SetVertexCount(1);     
    }
}

Dealing with Console Warnings

When it comes to dealing with these warnings we have a couple of ways we can approach them.   First off and arguably the best way is to just fix them.  Adopt a policy of “No Warnings” and as soon as you encounter them you deal with them.  Consider this?  Can you risk a chance of letting in a bug just because you couldn’t be bothered and ignored a warning?

Remember, Some compilers may provide a hint how to resolve a specific warning.

However, you might be thinking “Since there are only a handful of warnings, I can live with those.”.   So let’s say you leave them, how long are are you working on the project before you start just blocking them out completely.   New one’s pop in as you go but you just say that’s alright since it’s just one or two more, before you know it, they all look the same and then in the middle there’s a crippling bug that was ignored due to blending in.   Dealing with the warnings is the only safe option.

Remember, Don’t fix compiler warnings mechanically, fix them with thought & purpose.

Clearly, we hope you agree that dealing with warnings by correcting or cleaning up the code to the point it is clear for the compiler is always the best option.   However, there are options how we can tell your compiler which warnings we want to see and which ones we don’t.  If the code is not clear to the compiler, there is a good chance that it is also not going to be clear to some human readers either.   It’s always better to clarifying your intent in the code than to silence the compiler.

While there are occasionally justifable situations where we just want the compiler to silence a specific warning.   The majority of compilers usually come with special `#pragma`s to turn specific warnings on and off in code.  When it come to using these`#pragma`s it should always be considered a workaround, since they can have their own problems.

In C#, when we turn off a warning with `#pragma` we are silencing the compiler regarding that warning for the particular script for the rest of the compilation unit.  It’s important to know that `#pragma`s for warnings are not portable between compilers.    The identifiers for a given warning vary between compilers as well as the format for the `#pragma`.   Compilers sometimes will emit warnings about unknown `#pragma`s.  With that in mind, if you use them, use them sparingly.

Now let’s take a look at that script and the warning that it will produce from the compiler that we can see int the UnityEditor console window.

As the compiler was provide us with the warning notification we can see that with this script we have the following warnings:

  1. Warning CS0642: Possible mistaken empty statement
  2. Warning CS0618: Method/Function is obsolete, use Method/Function instead
  3. Warning CS0414: Variable is assigned but value is never used.

These can come up pretty often when you find yourself working on a new feature or tweaking a previous one.  When you stop using the previous variable, you will be presented with the following warning from the compiler.

Warning CS0168: Variable is declared but never used.

Often times you will have a bunch of variables you are tweaking and modifiying and sometimes your using them in the code and other times your not.   These warnings are obvious and can be ignored.  We can use `#pragma`s to silence the compiler and remove all traces of the console warning.

As you can see from the image, we can use `#pragma`s to silence the compiler warnings from within Unity by adding a statement to our scripts.

  1. Go to the very top of the script.
  2. Add one #pragma line for each warning you want to disable (see below)

#pragma warning disable 1234

So for the unused variable we would use: #pragma warning disable 0414

We can disable all three just like this:

#pragma warning disable 0642
#pragma warning disable 0618
#pragma warning disable 0414

Your script should now look like this below:

You can also disable it for a specific variable in the script, rather then every occurrence.  For example: Let’s consider we have this variable that is unused and  that we just want to stop the warning on this particular variable.

Where as the approach before was at the top of script to write: #pragma warning disable 0219 // variable assigned but not used. but now we want it to only apply to one specific variable.  We can simply do this by marking it disabled before the variable and then restoring the error after the variable.

 #pragma warning disable 0219
 int variable = 1;
 #pragma warning restore 0219

It is important to remember that this approach will work for warnings found in a particular script only.   They will not apply to the same warnings within other scripts.  But what if we want to approach warnings by disabling them everywhere within the entire project instead of just a particular script.    As an experienced programmer, this is likely the most useful to use.

Steps to Disable Warnings Project Wide

  1. Right click on the Assets folder in the Project window and select ‘Show in Explorer’.
  2. Double-click on the Assets folder and once inside create a new file called “csc.rsp”
    (If you use text document make sure you can view the extensions so you can change it from .txt to .rsp.)
  3. Save it in the Assets folder of your project

Once we have the file we can being to add warnings to disable project wide.

For instance, we would add these lines.

-unsafe
-nowarn:0414
-nowarn:0642
-nowarn:0618

The syntax is: -nowarn: 1234 where “1234” is the exact number of the warning that appeared in the warning message in Unity console.

So instead of #pragma warning disable 0219 // variable assigned but not used.
We would add: -nowarn:0219

This way we can control these warnings across the entire project and silence those warnings we know we don’t want to see.

Benefits of Dealing with Console Warnings

  • When all the easily fixable warnings have been fixed, the remaining significant/relevant warnings will stand out.
  • If the relevant warnings are found and dealt with on a timely basic, bugs can be avoided, thus leading to better end user satisfaction
  • Solving the warning leads to more maintainable and simpler code (e.g. eliminating conditions that are always true)
  • When amount of warnings is closer to 0, it is easy to agree on Zero Warnings Policy.
  • When solving compiler warnings, understanding of the program code deepens, which may lead to useful insights about the implementation.
  • Build gets faster, daily productivity up: IDE/compiler has less issues to manage and report on, thus compilation is faster (this is relevant in the context of thousands of warnings).

Remember, compilers point out these warnings for a reason, they are not meant to drive you crazy and compiler writers don’t actually put them in just because of some mean-spirited joke.  Many warnings are helpful and contain useful information that can help you become a better programmer.   Like we mentioned before, if the compiler doesn’t really understand what your trying to say in code, chances are a human will have the same problem.

So remember to deal with your warnings and clean up your code.   Take your time and examine each error and inspect the code it’s coming from.

Deal with your errors because they are dangerous and deal with them carefully.   

Become aware of the warnings that are more likely to be bugs or cause problems later on and recognize those warnings that are likely to cause bugs or problems when you try to fix them.   It’s always best to write clean code and get in the habit of not leaving warnings behind in the first place with any code that you write.

Image-Logo-AresTheDogStudio

ProgrammingUnity

GameDevProgramming

AresTheDogAuthor posts

AresTheDog Studio Administrator.

Leave a Reply

Your email address will not be published. Required fields are marked *