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:
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.
5 Likes
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.
3 Likes
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
#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â.
3 Likes
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.
1 Like
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.
1 Like
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.
1 Like
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:
- The game kept passing function parameters through global variables. (Because everybody loves side effects)
- 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.
3 Likes
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.
3 Likes
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. 
1 Like