Declaring a private field and never using it does not produce a warning in Unity 2019.2 and 2019.3

Declaring fields in a class and then never referencing them does not produce a warning, neither in Unity nor in ide (Rider)

Warning I would like to see:
https://docs.microsoft.com/en-us/dotnet/csharp/misc/cs0169

Does anyone else have the same problem with this? It also happens when I create a new project.

 

Good. That error is totally useless within the unity context. I'm sick to death of having to scroll through dozens of warnings telling me that I'm not using a variable when that variable is specifically designed to only be touched from the inspector.

 

That's not really the solution to this problem, you can't just ignore unused non serialized private fields.

 

Ideally the compiler would be able to tell the difference between a serialized and non serialized field, and only throw the warning if the field was non serialized.

However if that's not possible, I would prefer ignoring the warning altogether.

 

Why? By being unused and non-serialized they're not going to affect anything, and because of that I can't think of a single reason why I would need to care if it exists. Worst case they consume a few bytes of memory and show up in IntelliSense.

That said see if following the directions at the link below to increase the severity level solves your problem in Rider.

https://www.jetbrains.com/help/rider/Code_Analysis__Configuring_Warnings.html#change_severity

 

You can, though. I mean it isn't doing anything by merely being there.

 

you always can disable specific warning message using

Code (CSharp):

1. #pragma warning disable xxx

 

Well while some of you don't bother if you have unused fields in a class, for me they are making code less readable and maintainable and they increase memory usage since compiler can't remove them due to reflection. I also understand that you hate seeing tons of warnings for using private serialized fields, but at least this can be worked around with assinging null. For now I didn't find a way to re-enable warnings, you can see them in some IDEs.

Already tried, didn't work but rider is working on a solution so you can override those settings.

 

We never said we don't bother. We said that there isn't a requirement to remove them. Your wording implied there was.

Only a trivial amount in the vast majority of cases. For value types (basic data types, structs, etc) the amount is allocated when it is declared, but for reference types only the reference is allocated. Since it would be unused a reference type would never be more than a few bytes at most.

Agreed, and this is the real reason why we do it.

 

The amount of memory used by a field is negligible.

Those warnings are often annoying because some editors do not have a dedicated "compile" button and compile code when you stop typing.

"Hey, this field is unused!!" "I KNOW, I'm still writing code for it".

 

The main problem with unused fields isn't the performance loss (except if you have several billions of them of course...).
The problem is that it may generate bugs.

There's no reason for having unused fields, so why are they here?
Most of the reasons are harmless, but some may generate bugs.
For example, it may be a misspelling.
For example, if the field '_lives' is unused, and if in a method you have a parameter 'live', and in that method you want to use the total number of lives (obviously '_lives') but you misspell it and write 'live' instead.
It will compile and execute fine, but it probably won't do what you want it to do.
If a warning is issued, then you will fix the error before the execution itself.

Of course, in these cases, most of the time you also use the field somewhere else, so there's no warning.
But sometimes, maybe once out of 10000, it will help you.
That's the reason why warnings do exists.


If you just ignore warnings because fixing them isn't a requirement, then you will have a lot more bugs to fix than you would have if you took care of a warning when it pop-up.
And anyway, if you really want to ignore warnings, you can always uncheck them in the 'Error List' panel in Visual Studio, that way you'll never see them.

 

This is incredibly far fetched. Pretty much on "hash collision" level.

C# lacks many other bug prevention features present in C++, and those would have higher priority and higher impact than a forgotten private field. Except people still use C# despite that.

I think it is important to understand that writing a warning-free code is not an inherently good thing. (see: https://zlib.net/zlib_faq.html#faq35 )

Believing that it is an inherently good thing is highly likely a cargo cult.

in case of this particular warning, the only negative side effect is noise in the program code. The other costs are negligible.

 

I have already avoided 3 bugs in my career (about 20 years professional, and 15 years before that) because of that specific warning.
Twice on code written by someone else, once on my own code.

But I admit that better warnings do exists. I would really like having something indicating we are using a local variable with the same name as a field/property, or a keyword... I lose a few hours each time I stumble on code with these horrors.

 

I have read the three sentences you pointed out here.
They are wrong.

They assume the code is made to be compiled on a lot of different compilers, which is very rarely the case.
In my professional career, I always saw projects where the compiler to use, along with its configuration/parameter, was specific in the build manual.
From what I have seen in large company of different types of industries (trains, planes, medical, nuclear, etc.), you have very precise instructions and tools, you aren't free to use any other compiler than the specified one.
It's a very important step in order to ensure that what you see/compile is what you are intended to see/compile.


If I follow the logic of the link you provided, it means that warnings must ALL be ignored.
I say 'ALL' because it is said in your link that they gave up removing warning and just wrote code that works, meaning that when they reach about 500 KLOCS, they have several thousands ignored warnings flooding them.
Meaning that when they write something wrong (we all do that now and then when we code) which generate a warning which tells them that they made a mistake, then they simply have to ignore the new warning.
Why do they 'have to' ignore it? Because it is lost among thousands of warnings so they cannot possibly see it.


If you ignore warnings, you are willfully preventing you from using a tool which could prevent you of doing some bugs.
And some warnings can indicate bugs which can be very hard to find out otherwise.

Like the warning which indicates you that a constructor will be called after a method which is using a field initialized in the constructor (meaning that, despite the fact that you have initialized a field in the constructor, you will in fact use it in a method without it being initialized, which is quite hard to find out without some help from the compiler).
I really like to see a warning about that one, it always saves me from hours of useless debugging.


And for information, I am specialized in code review.
When I review a code, I always find at least one bug without even executing the software.
Usually, I just compile it, look at the warning, and read the code around some warnings.
I always find at least a bug like that, I do that to prove the devs that the rules aren't there 'just to bother them', but that they are there to actually fix some bugs.

 

One occurrence per 5 years. (-_-)

They're not.

The library in question is written in C language, so a multitude of compilers exist for it, with varying degree of sanity.

No, that's a strawman.

Warnings can be generated for many reasons, and in some cases the warning is not generated because compiler developers have your interests in mind. (Google "_CRT_SECURE_NO_WARNINGS").

Al I'm saying is that developer should not be using cargo cult mentality. And "number of warnings generated should be zero" is exactly that. Instead there should clear understanding whether this or that warning is useful, and why. If you do not have clear understanding why, you're partake in cargo cult rite, and your tool might be generating informational noise for you which will obscure other problems.

 

For one type of warning, multiply that by the number of types of warning there is, and you'll see that I've spent less time removing the warning than I would have lost trying to fix the bugs I never made.

You're right, I missed the C point.
First, it is a Unity forum, and, except if you're hacking Unity directly, the language is C#.
Second, removing warnings is still mandatory in C when you're working with planes, trains, in medical or nuclear safety.
And when I say 'mandatory', I mean that if you have one warning in your code, then you cannot put it in the hardware you're working on.
Anyway, the quality assurance will find out your warnings and the software will never get in the a plane or nuclear plant.

Note that I was never part of a community project, and maybe there warnings aren't important, I have no idea as I have no experience there.

The problem is that if you let some warnings go through, how do you see the new warnings? Aren't they lost in thousands of not-removed warnings?
I mean, you said that we must understand if a warning is useful or not, and why it is. But how do you ask yourself that question if you do not see the warning in the first place?

Also, I do not care if you tell the compiler to ignore some warnings.
I mean, if you configure it not to display some types of warnings, or if you add a pragma to ignore a warning in a source file, it's perfectly fine.
The thing is, it's a very good thing to have 0 warnings when you compile.
The goal is to see any new warning, and to decide what to do about them (writing the code a bit differently, or adding a pragma to ignore it).
How you remove them is up to you,
Your are a lot better than the compiler to know how to deal with a problem, but in order to find a solution, you need to see the problem in the first place.
The only goal of the warning is to show to potential problems, not to magically remove all bugs in the software, the magical part is up to you.


2 years ago I began working on a 5 years old game of about 120 000 lines of code with over 2000 warnings.
The first thing I did was to remove all of them.
While doing it, I found out 2 bugs, one of them had been reported and has been eluding the original team for months, the other one has never been noticed by any player.
These 2 bugs should never have been there in the first place, there was no reason not to fix them as the compiler itself pointed out the bugs.

 

We're in a gamedev forum... why are you bringing up nuclear plants?
I'm certain that at some point at least some engines had clauses which prevented them from being used in those areas specifically (or was it just java?).

Those areas have a bit different approaches, when they're taken seriously. And that is to write program in such way that it is impossible for it to crash. As in, no matter what happens.

(Captain Obvious Mode: On)
You review type of warnings, disable those that you deem insane, and let the rest through.
You see them the first time you encounter them.
Faulty tools are a thing. For example, Visual Studio has intellisense warnings that produce tons of false positives.

LOC is a fairly useless metric for estimating complexity. Give the size of codebase in bytes, and that will give a better idea of what you worked with.

Many years ago I worked on, I believe, at least a decade old (should be 20 years old at this point) codebase that was ported from dos, then to OS/2, then to windows and my job was to make it run on directx instead o GDI. I think it was something between 3 and 5 megabytes total of a, well, inherited/legacy code.

The thing is, the codebase had a problem where it kept crashing and caused page faults... which, upon investigation was caused by two reasons:

1. The game kept passing function parameters through global variables. (Because everybody loves side effects)
2. The game was written with assumption that true parallelism is impossible. (no dual-core cpus existed when the very first version was made).

To investigate the problem, I had to hijack memory manager, and make sure every access to every dangling pointer triggered actual HARD page fault/crash by the OS, using variation of VirtualProtect. Thankfully, the computer at this point had just enough RAM to allow page-aligned allocations. The resulted problematic spots were then secured by critical sections and it stopped crashing.... I think there was also a patchwork of fixes targeting isolation of global variables into namespaces, as proper fix was not possible.

So, why am I bringing it up....

Amount of warnings: zero. From start to finish. No diagnostic message was ever produced that would provide any assistance in any part of the project.

Don't get hung up on one type of diagnostic message and don't go cargo cult on them.

Have fun.

 

To play devil's advocate, I frequently write scripts by adding most of the public/private variables and empty methods first, then fill out the functionality of the class afterwards. On rare occasion I've gotten the script basically functional but not 100% complete and moved on to other parts of the project, with some unused variables left for functionality not yet implemented, and forgotten I still had this work left to do. Then a few months later when I feel like scrolling through all the warnings I notice the unused variable messages and remember I should go back and finish that part of the class. In the last few years I've been helped in this manner maybe twice.

But overall I agree with your statement.

 

Listen to yourself. It was useful three times in 35 years. And yet due to the structure of the Unity inspector, I saw this warning about 30 times in a weekend game jam. This warning will literally spit out thousands of times in a big Unity project. And it might be useful once in a thousand instances. Nobody is going to check each and every warning just to be sure that it isn't genuine. Console spam just makes seeing the important stuff much harder.

DO NOT USE UNITY TO RUN YOUR NUCLEAR POWER PLANT!!!!

Or a plane. Or a train. Or anything medical. Seriously. You will kill someone. Unity isn't designed with real time control or safety in mind. Unity's failure on demand rate would easily be upwards of a thousand time per year. That's totally acceptable in a game where the consequence of a crash or bug means you just have to hit "restart". Its not acceptable when lives are on the line.

 

And fixing the problem those three times likely took them far less time than the cumulative time they spent correcting the countless number of warning messages over the years.

Again not saying I don't fix them myself. I correct them when they appear because they do annoy me and my other team members. Just saying they're almost at the level of a personal preference as to whether you correct them. Kinda like the "var" keyword. Choosing the type can save you from potential bugs but it's still considered a personal preference.

Unless I'm misunderstanding your post I don't think it's devil's advocate when you say that it has only helped you twice in a few of years.

 

In fact no.
The reason, I haven't 'only' fixed that specific warning, but also countless others. And I have avoided a lot of bugs thanks to having fixed all these warnings.

In addition, I am so used to avoiding the warnings, that I nearly never produce any warning when I code.
In fact, in the last year I have generated about 10 warnings out of about 10k lines of code. In fact I produce a lot more spelling errors than warnings...
And the fact remain that each time I review some code, there are a lot of warnings, and by looking into them for about 30mn, I always manage to find out a bug, which proves that warnings do help finding bugs.


Anyway, my point was not that this specific warning is important.
My point was that what is important is to never have too many warnings, because you cannot see the important ones if they are among thousands of unimportant ones.

What's important in the end that you have to decide in advance which warnings you want to see, and which warnings you want to completely ignore (by forbidding the compiler to show them).
But ignoring warnings displayed by the compiler is a very bad practice, and leads to more bugs than necessary, especially when there's a lot of KLOCs.


If the OP finds this specific warning important to him, then he has to find out a way to display it.
And for that there are tools, like Resharper, or Visual Studio's code analysis (found in the 'Analysis' tab, next to the code metrics).
And none of us can decide for him if he is right or not, simply because we do not know anything about the code he's writing, the context he's working in, or his own habits.

 

Compiler warnings are useful for the same reason static analysis is useful - it's automated code review.

It's to flag something in case you don't know about it, not for the situations where you do know about it, because sometimes it will be the result of a coding error.
If you know it's not an error, and it's just temporary while you are working on something that's fine, the warning will disappear when it's sorted out.

I was doing some code refactoring the other day and got a similar warning about an unused variable.
My first instinct was to say "it is being used, what are you on about!?"
But I had messed up. The variable was being redeclared in local scope so the public declaration was unused and the code wouldn't have been doing what I thought it was.

The warning identified this immediately and I could see it straight away because I had no other warnings in the console.
If you ignore warnings to the extent that you have so many as not to notice new ones, it's highly likely you are sometimes introducing bugs into your code - and worse, they were things the compiler told you about.

Obviously if you are working on your own in a hobby project you can do what you like.
But in many software companies it would be against coding standard to ignore compiler warnings.
Fixing them may be to agree to disable the warning (as long as there was a valid reason), but you wouldn't leave the warning in the console.

Similarly if you are releasing a library it's not good practice to leave compiler warnings in the code because you are passing on the grief to users of your library.

 

Same here. Member vars I'll probably use later are most of the "unused variable" warnings I get. Commenting them out to "fix" it seems pointless -- I'll have to uncomment them tomorrow when I use them. Similarly, I might have code that computes a bounding box in a local. In the code after it, old version A used it, current version B doesn't, but that could change. It's easier to leave it there and ignore the warning.

The main use for that warning seems to be end-project clean-up. Maybe 10 years from now the C# world will have warning levels A and B, and people will chuckle about how "unused variable" was once a level A warning.

 

But that was a fluke. If the global had been used anywhere else, you wouldn't have gotten the warning. And it's not like it saved an hour -- "shadowing" errors are usually easy to notice -- the function never does anything -- and are generally quick to spot if you're not tired.

I guess I'd say that if you want to fix all warnings, don't do it as you go. That makes it a drag on your productive "in the zone" time. Warnings don't take deep thought to fix -- do them when you need something easy to work on. Maybe when you're stuck on something else, fixing warnings is like a mini-vacation.

 

Maybe it's coming from C++ background that I find this thread so puzzling.
In my day job in the games industry I'm not able to commit any code in that has a warning because it would compile as an error.
We are literally prevented from doing so as it would be against the coding standard, and I don't think this is unusual in larger software studios.

Since we adopted this approach are code quality has improved greatly. We used to have hundreds, probably thousands of warnings in our codebase. Many of these warnings were hiding errors and it was a mess.
So taking my C++ experience to Unity, I don't check-in code that has generated a warning, I just fix the warning.
And sometimes, like the example provided, the compiler has stumbled on a genuine mistake.

Maybe I've just not come across the same situations in Unity or C# that many of the respondents in this thread have, so my perception is different.
But like I say, I think compiler warnings and additional static analysis tools are great, and help me on a daily basis, but naturally everyone will speak from their own experiences.

 

Warnings are not errors. At least not in C#.

A warning means "something might not be right". An error means "something is definitely wrong".

The reason for the general blase attitude about warnings on the forum is because many of the warnings were not designed with the Unity environment (and the inspector in particular) in mind. For example you can assign values to private variables via the inspector. This is considered good practice in Unity development. But the compiler will still throw a warning.

 

To be clear, I know the difference between a warning and an error. The fact they are there to tell you something might not be right is why I think they are good.

My point is that to enforce coding standard you can prevent developers checking in code that has one or more warnings by triggering a compile error. It’s called “Treat Warnings as Errors”.
This keeps the codebase clear of warnings and I don’t think it’s unusual practice in large software houses that may have tens or hundreds of developers.

So I’m literally not able to commit code with warnings (because it will compile as an error and not build).

Because I’ve seen the benefits of this approach, albeit in C++ environment, I take the same approach when working in Unity.

As I said previously, fixing a warning may be to agree in your team to disable that specific warning type if it’s more hassle than it’s worth, which I assume you can do in Unity, but I’ve never come across a reason to do it yet.
Although your example is interesting, I will look into this.

This may just be an issue of scale. I’ve seen what having a relaxed attitude to warnings can have on really large projects. It can quickly get unmanageable and hide serious problems.

It’s less of an issue on solo dev projects where you aren’t inflicting the warnings on others. In larger game development houses you will often be working on a library which is shared throughout the company and not an isolated codebase.

I just wanted to share my experience with warnings from working at a large software house, because a relaxed attitude to warnings will often go down badly, and I think, for good reason.

 

Coming from C++ background you should be aware of shenanigans such as _CRT_SECURE_NO_WARNINGS and Warning C4996.

Also, fun situations when compiler developer introduces a warning that breaks compilation, because you're working with 3rd party codebase which just happen to have few hundred megabytes of code in it, supports multiple compilers and works perfectly fine BUT currently has warning as errors enabled.
--------

It is worth mentioning that verifying coding style is not compiler's job in the first place.

 

Well, good. I feel like these would help:

o What are the typical C++ warnings you fix? Are they also C# warnings? I'm thinking of: not assigning to an "out" variable, redeclaring a parameter as a local, casting an int to a char-array, using a void* pointer, const correctness, using n++ in a larger expression (I think that can be a warning).

o Is an unused variable one of the required warnings to fix? unreachable code? Those are 99% of the ones Unity gives me.

o Are the must-fix warnings determined by a manager, or are they from IBM's official C++ warning site? The errors and warnings in Unity are pretty much whatever microsoft says.

I feel like fixing C++ warnings is a completely different world from C#, since C# already makes so many warnings into errors, and discourages choosing what you want to be one.

 

If you think about it, a warning is worse than an error. I'll try and explain my thinking...
An error cant make it into release because it simply wont work, you have to fix it.
You only ever release code that compiles, because otherwise you can't build it.

A warning is where your code compiles, so you can build and release your game.
But there's a chance it's not doing what you designed it to do and this can make it into release, because it wont stop you building.
A warning may be a bug that will affect an end user, a compiler error wont affect an end user.
It doesn't make sense if you think of it like that, and that's why the concept of warnings = error, is good.

​

Having a no warnings policy doesn’t mean you fix all warnings regardless of what they are. It may mean you disable specific ones, as I said previously.
Certainly in third party code they tend to be disabled, so it wouldn’t generate an error in that case.

My point is just about not leaving warnings live for no reason, which if you are working on large scale projects is really important.
It forces you to make an informed decision about a warning, instead of kicking the issue into the long grass, where it may never get fixed, because they will quickly add up to the hundreds and thousands.

You don’t randomly change compiler during a dev cycle, in the same way you wouldn’t randomly change Unity version, or randomly update a third party library.
This is planned for and done at appropriate time and you address any such issues away from live development branch.

But building on lots of different compilers is a good thing because it means you’ll get even more warnings, and they will find even more bugs for you.
I prefer to code on a Windows dev machine. I know my code is warning free on Windows before I check in because I will get a build error otherwise.
Once checked in, an automated build server will compile for all target platforms.
At this point it’s quite possible a build error will occur, say on XCode due to a warning.
This is a good thing because I’m aware of it immediately and can fix it. It could be something serious like a casting issue losing data.
Without the warnings as errors approach I wouldn’t even be aware I had broken the game in this way. All the warnings would stack up and never get fixed. It wouldn’t even be clear who was responsible for introducing the warnings in a large team.
But over time, some of these warnings will be real bugs, some quite serious bugs, and the quality of the game would suffer if they weren’t being fixed.

​

There's a difference between a coding style, which is unique to everyone, and a company coding standard that everyone must follow for the benefit of the whole studio.
If in the coding standard you all agree to treat warnings as errors, why would you not automate this process and use the available compiler options to achieve it, to make it impossible for people to break the standard?

As I've tried to emphasise, I completely understand that C++ on large projects is a different beast to what most Unity devs are dealing with and I'm not suggesting every hobby Unity developer has to stress about warnings, and some of what I've said just wont apply to everyone reading this. But I've seen first hand the difference it can make to treat warnings seriously, so I naturally just adopt a similar approach when coding with Unity.

 

A group of senior coders in the studio make a decision about what warnings to disable and to finalise the coding standard.
I think the intent is to have as high warning level active as is feasible.
Certainly unused vars and unreachable code are active warnings so would compile as errors.

A warning may be the only clue you are going to get about a bug in your code before a user tells you about it or your game crashes.
If you have been refactoring a complicated AI function, or something like that, it's not unheard of to get an unreachable code warning telling you half the code will never be hit because you've messed up somewhere.
This may be near on impossible to pick up on in testing and your only clue was the compiler warning.

But I completely understand that if your only experience of this warning so far in Unity is when its annoying you because you haven't finished coding your function yet, I get where people are coming from. I just want to make clear that in my experience all these warnings that seem quite harmless (and are a lot of the time) can be the result of serious bugs sometimes, so it's worth checking.

Unused var warnings are common when writing platform specific code where you declare it in function scope but only use it in platform specific code that is conditionally compiled within that function. In this case the warning helps you tidy the code up, which is no bad thing.

 

Your responses left me with the impression that you're interpreting the responses we're giving the OP as "warnings can be safely ignored". If that's the case then I can understand why you'd find it puzzling. We're not actually saying every warning is safe to be ignored. There are many you don't want to ignore. We're just saying THIS warning can be ignored.

To my knowledge there is only one situation where an unused private field can affect a program and that is if the program is using reflection to bypass the access modifiers, but if you're bypassing the modifiers you're bypassing the way the code is intended to be used and are going to run into problems regardless of this warning.

 

It might be that the warning's not there because Unity implemented this, but targeted 0169 as well as 0649. 0649 is the error for "not written to" that I imagine @Kiwasi is complaining about here and in other locatons in this thread, which is a different warning.

The 0169 warning that the field is "never used" means that it's not read from, which means that you should delete it. if it's referencing an asset, it could drag an asset and all of it's dependencies into a project. If that asset is a prefab you're not using, then... yikes.


If it's the case that the surpressor has been implemented, and that it targets 0169 as well as (or instead of) 0649, then that's a bug that should be fixed.

EDIT: looking into this, it seems like that's not the case. It seems like Unity's just not reporting the compiler warning?

 

Oh, and if you don't want 0649 (say, in the case where you're @Kiwasi), you can surpress that by stuffing a file named csc.rps in the root of your assets folder, and putting this content in it:

-nowarn:0649

 

I would generally fix this warning. There isn't anything I'm aware of in the unity environment that will somehow reach your unreachable code.

On the other hand there are things in the unity environment that will can use the unused variable.

 

This will pop up during debugging by disabling function with early return. So most of the time it is noise. Still, it is more useful than "unused variable".

 

Yes, those are where mine come from:

int getHappiness() { return 5; (real happiness code here) }

and such. I even have a few long-term ones. If I'm 75%+ sure I'll need the real code somewhere, eventually, I like to leave it active and uncommented -- that forces me to keep it current. The warning is almost a nice reminder.

I don't think I've ever gotten a real Unreachable Code error. For example,

if(n==1) ... else if(n==1) // oops, used 1 twice

(it doesn't actually detect that one, but it could).