Do you fix warnings?

Just wondering if you guys fix warnings? I've got into a habit of hiding the warnings in the console & now i have about 500 or so. Makes me think I should do something about them....

 

I always try to resolve warnings just to be on safe side since some warning can cause issues later on the road.

 

I fix all warnings immediately, except the ones that say that a certain variable is unused. Of course only if i know i will need that variable later on.
When you deal with a warning as soon as it appears, it's usually fixed really fast, but i don't envy you with your ~500 warnings...

In all honesty, a warning is something that should warn you...if you have so many of them, you stop caring, which sounds like you don't care about your code.

It kills me when i import a third party asset and all of a sudden i have warnings all over the place. This is simply unprofessional and should clearly be avoided in assets that get on the asset store. Maybe i care too much about my code, but i love coding and you treat the ones you love with respect

 

Depends. Most of the time warning point to unfinished areas in code. Places I started to write something, and never finished.

If I know I'm going to finish these later, I'll leave them. Otherwise I'll comment out the code.

This drives me insane too. It's not just third party assets, I've had team members that do this too.

On a similar note you should remove all Debug messages from code once you are done with it. Or at least wrap them in a conditional. On large projects it sucks to have to read through a hundred other debug messages just to find your own.

 

These are not from my code but 3rd party assets.

 

If I'm not mistaken, Unity's Debug calls get into release builds and generate log output, right? So that makes them especially bad in an asset, if you ask me...

 

This, expecially when you are testing on iOS where you can't breakpoint, and xcode is verbose as F*** and prints whole stack traces for every log. It can be nearly impossible to find your log statements in the rest of the clutter.

 

They are also rather expensive calls

 

before using Unity I would never, ever have let a warning live in my codebase. Now I have hundreds.

3rd party assets are a huge problem, once you drop in a new plugin and you get giant amounts of console spam, it's over. I might have kept fixing my own warnings, but it's really hard to separate the two.

Heavily customizing an asset to fix warnings is problematic since you make it harder to update. Even if you do happen to take the time to prune warnings from third party, once you click 'update' and the warning spam comes back...

It's actually not worth fixing in many cases... which is kind of crazy.

 

If I wrote the code, yes. Someone else's code, no.

 

I focus on creating as many warnings in my code as I can, because I like to live on the edge.

 

I always fix them.

If I'm working on something new that is mostly stubbed out, then I just suppres them from that class until I am nearly done with it.

 

I view an asset with loads of warnings as a simple choice.

1. Fork the code. This is now my asset that I maintain and there will be no more updates ever.

2. Dump the asset. I don't want the job, and whoever wrote this isn't doing his so I won't use it.

Usually I pick (2) because ain't nobody got time for that.

 

"Variable is declared but not used" because [SerializeField] isn't recognized by the compiler as used implicitly is a good example and probably the most common, followed by 'private void Update()' never being called and the like.

Do compilation warnings like these really outweigh the potential for updates and bugfixes on complex plugins?

NGUI is a nice example, this was a large and reasonably complex API that was regularly updated with small fixes and improvements. I don't remember if there were warnings or not, but I would guess that there were quite a few.

Freezing updates on 3rd party code is a necessary evil due to practical considerations: deadlines, dependencies, custom modification not a goal in and of itself. Avoiding updates and bugfixes because of generally meaningless compilation warnings (usually due to Unity having usual workflow from vanilla .net) just seems like programmer vanity to me.

How much value does spamming #pragma warning disable 0168 everywhere really provide?

 

Yes. A developer who is neither fixing nor disabling the warnings on his asset is not only crapping up my console with worthless chaff that may conceal a very important warning, but also his own. It is sloppy and makes maintaining his own asset more difficult. That means he doesn't really care if he can find and fix problems in his own asset quickly and reliably, which bears rather directly on the question of whether his updates and bugfixes are worth getting.

It tells me what kind of developer you are. You have three choices.

1. Stick the pragma in your code so the warning goes away.
2. Tell customers concerned about the warning to ignore it.
3. Ignore any customer inquiry about the warning altogether.

Only one of those is anywhere near what I consider professional.

 

What I do is if I am writing a code base, or a script or whatever else. I'll wait until it's completely finished then I'll go back and remove these pesky warnings. I generally start to write something just to jump to something else that's more dire, then realize at the end I didn't need something after all, so I leave it until I an satisfied with what I am writing, then I'll go back and remove the stuff I ended up not using after all.

But I always deal with them. Just some I push back until I finish the script as generally I want to go back and finish it, but not always, sometimes just remove it all together, I keep the warning so I can easily find it later to remove it/fix it.

EDIT:
Generally the only warnings I ever get is 'Some Variable isn't used' kinda of things. As mentioned I start something, go to something else in hopes to replace it.

 

This.

I believe it is reasonable to expect that any paid asset should be free of warnings/errors. (With minor exceptions)

 

Yeah the only minor exception I can think of is something that happened to me, you release an asset, everything's fine (no warnings and errors), well - next Unity version comes out - warning present... Well - removed the warning and re-submitted lol.

 

Yea, that is what I what I was mostly thinking of. I would expect the asset developer to fix those cases eventually. There are also times where a Unity update (usually patch releases) introduced warnings that were eventually corrected. Also, if a there is an asset with a fringe/specific usage (usually editor related) that generates warnings, and that is very clearly explained in the asset.

 

I don't generally get patch releases because I read somewhere that you should only get them if you experience the bugs they fix. I don't generally run into bugs, so never had a reason too download them, only have once back when 5x first came out.

But yeah, I generally check my assets every second update E.G. 5.2 - 5.4 this way they can fix the things between two versions. Now if I see thousands of warnings - yeah headed right on to fix it lol.

 

To each their own.

I've personally come to the conclusion that for Unity specifically, paying attention to compiler warnings is kind of pointless.

Instead, I tend to use other tools to identify problems like Resharper. These kinds of tools give you more direct control over finding potential problems. Example screenshot (from resharper webpage):



Modern tools like Resharper just do a better job. They're highly configurable (so you can ignore stuff that doesn't matter like private fields you're exposing to editor being marked as never assigned), flexible, and allow for things like attribute based annotation. Unity even distributes the jetbrains annotations dll with the editor!

Worrying about warnings for the sake of code vanity is a nice luxury (I miss it honestly, and hate seeing warning spam still), but if you really want to use warnings to identify problems - there are simply better ways than sticking pragma's everywhere and suppressing.

Don't add more work to your plate when there are such solid tools that can do it for you.

 

I fix every warning I get when I'm making something unless it's an editor extension because christ I am just god awful at making those and my code is too much of a mess to fix.

 

5.6 has added hundreds of deprecated warnings to my current project from 3rd party assets. As far as dealing with them, I'm going to watch for updates on the asset store for those assets. That's about it unless I notice some broken functionality.

 

I used to fix them all at first. But as I started getting new ones whenever Unity updated, and I gradually starting postponing fixing them until I just set them hidden as long as it didn't hurt functionality.

Over time I even forgot they're even there. Though I'm thinking next project I might be more tidy, and also use c# instead of js.

 

At first, I had a problem. Then I thought "I will go find a tool to solve this problem." Now I have two problems.

I worry about warnings because they breed complacency and laziness.

 

In my own code, I usually ignore warnings until the thing I'm working on is functioning correctly, and then I clean it up. From an asset store product, I don't want to see any though.

 

Again, ymmv, but tools like resharper give you access to better options. Try it (or similar) if you haven't. It can really make your workflow considerably better. Filter compilation warnings as you wish, all kinds of additional control over exactly what kinds of problems get reported. If you can run resharper and don't, I'd recommend.

In all honesty, the stock C# compiler warnings aren't suited to Unity. Spamming pragma ignore is not an ideal answer unless you are selling the source and need to cover the lowest common denominator of users. Use a tool that fits the job.

Call it laziness if you want, but "correcting" an "error" in source by suppressing with pragma just seems silly when there are better options.

 

Hiding the problem because you don't care is not a better option.

Personally, I think you should write better code. If you can't be arsed, or there's really no better way to write it, use the pragma. If you think that's silly, because you have a tool that hides the warning so it doesn't waste your time, you still clearly have no respect for mine and I don't want to use your code.

 

The point isn't that you are "correcting" and "error". Compiler warnings exist for a reason. They are cases recognised as commonly leading to various types of errors.

If you ignore them then it creates the perception that you're not paying attention. If you #pragma them away then there's a higher chance that you're paying attention to them, because ideally you aren't just "spamming" the suppression, you're looking at the warnings on a case-by-case basis and deciding either "yeah, I should fix this" or "no, this warning is not relevant here so I will consciously disable it".

Just "spamming" it is no better than ignoring the warnings, because either way you're not paying attention.

 

Dude, turn off for a minute... If writing pragma ignore makes you happy and feel great about your code. Awesome.

The tools I mention allow you to do everything you can do with compiler warnings and more. If you want to actually find potential problems, then these are likely better suited to the Unity specific environment, as they allow you to filter warnings as you wish or present entirely different ones.

That a line of code generates a "warning" doesn't mean it's bad or wrong. Your code does not magically improve because you pragma ignore.

Warnings are a tool for identifying problems. In Unity, specifically, there is too much noise to signal. So use a different tool for identifying problems. If you aren't familiar with stuff like Resharper static analysis, then please, don't go around insulting people, go and check out some of the great tools you have access to.

The reasons they exist are to cover "general cases", the Unity environment is clearly not a general case, since it uses a number of uncommon techniques.

Think about it. Seriously. Does suppressing with #pragma make anything better? Are you changing variables from private to public to avoid a compiler warning?

If you're doing this just to 'filter' your warning messages, why not just use a tool that does that .. better.

 

I think he only means "spamming" in the sense that there's a lot of it, not in the sense that it's being done indiscriminately.

I think of it like code attributes. When you write the code, you know that you will need to put this attribute on certain things, or the code won't work. Similarly, when you write the code, you know that you need a specific pragma or the code will generate warnings. You should know the warning is going to appear when you write the code, so if there's no better way to write the code, you should add the pragma right then and there.

I mean, nobody complains about "spamming" public all over the place.

 

If you're using public for fields to expose to editor, you can mark the field with [SerializeField] and keep it private. It's very useful if you want to limit visibility.

It will generate a compiler warning though if you never set it from code.

There are other things like [UsedImplicitly] or [MeansImplicitUse] and a variety of other useful stuff. There are a lot of tools available.

 

That moment when one of the more experienced devs shares your opinion.

 

Not just a perception. . There are on occasion, warnings that are important, at least in the long term. Depreciations come to mind. When I first started using unity, I just ignored them. As time went on, warnings became errors. I wasn't paying attention to useful information. Now I make the effort to keep it clean. When I get a warning I can't help but pay attention.

 

​

Let me be absolutely clear about this.

I don't care what you do with your code in your project on your machine.

My code in my project, however, will be free of warnings. Because that is good engineering practice, and it makes maintaining and supporting my code easier for me.

So if your code ever ends up in my project, it will be made warning-free or it will go right the hell back out of my project.

None of this is about you or your project. It is strictly about me and my project. Your project can be whatever steaming pile of crap you want it to be, and I don't care.

 

I'm glad that you're so passionate about compiler warnings!

Let's take a deep breath and relax.

To clarify, what I'm saying is basically:

• Warning messages are guidelines the compiler issues to help you catch possible mistakes. They are 'warnings' and not 'errors' for a reason.

• The Unity environment has friction with these guidelines. There's a reason Unity codebases need to make use of #pragma ignore so frequently (this is normally a huge red flag)

• The meaning of [serializefield] in Editor, or magic methods like "Awake" or "Update" are highly specific to Unity. These things are very unusual, and make general guidelines less effective.

• Instead of modifying source to deal with the disconnect between Unity and the compiler, you can use other tools that may be better suited to an unusual environment like Unity.

Think of these messages as a 'view' on your code base.

You can either change your codebase to fit the view (suppressing compiler warnings via pragma, modifying visibility levels, etc), or you can change the 'view' to something that better supports Unity's workflow.

Assuming that a "good practice" is universally good, regardless of the details of the context, regardless of the domain, using them in place of critical analysis is...less than ideal.

 

600 warnings?

total of 939 warnings on my main project... yeh I stopped caring about it a while back after discovering nowarn...ones I look out for are the depreciation warnings, as those are worth fixing to avoid them becoming errors in the future upgrades. However all the other compiler warnings are all from third party plugins etc... I've since suppressed the fuk out of all of them using the mcs.rsp file.. the gmcs.rsp and smcs.rsp files no longer needed in 5.6 ...still took a look without the nowarns to see what level of warnings I'm upto now now ...

288 x CS3001 ...Argument type `UnityEngine.Transform' is not CLS-compliant

123 x CS3002: ...Return type of `UnityEngine.PostProcessing.ColorGradingComponent.GetLiftValue(UnityEngine.Color)' is not CLS-compliant

138 x CS3003....Type of `UnityEngine.PostProcessing.UserLutModel.Settings.lut' is not CLS-compliant

53 x CS3005.... Identifier`Hjg.Pngcs.Chunks.PngChunkBKGD.ID' differing only in case is not CLS-compliant

64 x CS3009:.... `ShowReplay': base type `UnityEngine.MonoBehaviour' is not CLS-compliant

etc etc ... what a mess I don't see .... It would be nice to clean them all up.. but given they are all from third parties it would be pointless updating them myself only to possibly see the author return them all again on an future source update.. just ain't worth the time... and now that I don't see the trivial ones the warnings that might be a little more important are more easily seen.

 

I always try to fix the warnings in my code, for one main reason: over time you will become used to them and won't notice an important warning that requires your attention. To me the (veeery little) time spent fixing warnings in my code is much preferable to having to read dozens of lines in the log several times to see if there's something important, or to potentially spend much more time in the future trying to find the cause of a problem that had presented itself earlier as a warning.

As for #pragma warning disable, I wouldn't use it (again, in my code), though I actually had to use it once because there didn't seem to be another way of fixing the warning (can't remember the details right now).

Now that I updated to Unity 5.6, my eyes bleed with so many plugin warnings, though...

 

That sounds like a recipe for a headache somewhere down the line. Nothing seems like a worse idea to me than carrying a half-rotten third party package around in my project.

I really wouldn't tolerate any warnings from third party stuff. If I want to sleep with my own bedbugs thats a different story.

 

What vendor has a plugin producing non cls-compliant warnings?? I've never even seen that. I had to look it up. Oh wait, so his assembly is marked as cls-compliant but unity's isn't - so Unity types are throwing the warning?

 

I think we may ask Unity Team to require plugin developers to update plugins may be within 1-2 weeks of production release and also require them to participate in beta releases otherwise those outdated plugins will keep us from upgrading to latest version. I love great work of plugin developers but I just get little panic with so many warnings. And it is just a good software development practice to keep the things updated. There are many plugin developers who always try to keep up with latest version of Unity.

 

You're not relaxed?

Similarly, they are warnings and not nothing for a reason.

Look, I added [SerializeField] to a private member and removed every reference to it, because that took like ten seconds in a script I had loaded anyway.

Code (csharp):

1.  
2.     [SerializeField]
3.     private Text tip;
4.  
5.     // Use this for initialization
6.     void Start () {
7.         // obtain component reference
8.         // tip = GetComponentInChildren<Text>();
9.  
10.         // load localised string
11.         // tip.text = LocalText.GetText(tip.text);
12.     }
13.  

I do not get any warnings about this. Why did you?

Clearly, because you were doing something else. But when you say the warning comes from having the SerializeField attribute on a private member you never access from code, that's not true.

But you're getting that warning for some reason. It's just not the reason you told me. It's another reason.

A reason you don't know.

Maybe you should, idk, find out?

But that friction doesn't just happen. You make it happen, with your code. Software has zero features by default. Every single piece of output that you get is because you did something.

Exactly! You can either fix the problem, or cover it up. And one of those makes you a bad developer.

 

It's ok i'm fine with it. you have to weigh up if the third party stuff is benefiting or not.. personally I like leaving warnings such as " CS0414: The private field *** is assigned but its value is never used " ....I leave those warnings showing from my own files because I often comment code out, but leave the fields uncommented that were used.... just as a reminder that I still have code that was using those fields.. I might come back to them at later point and remove them or finish what I started. Ofc warnings like that this come from third party packages are annoying I mean if you're gonna release something at least clear up that stuff that won't be used anymore. For my own stuff its different right

Ultimately the problem with suppressing warning with nowarn and mcs file, is that I while I don't care about third party warnings I might miss some that come from my own files.. but yolo they aren't errors so what of it.

Yknow what though... unity could certainly make warning suppression in the bare bones console panel better and provide an ignore feature for scripts in certain directories handling the nowarn thing at an editor level instead with some more finer control.. then I wouldn't need to use the mcs file to completely suppress certain warnings even when I'd rather it was just for certain script file paths. I'm sure the entire team working on visual scripting couldn't possible have someone make the console panel less naff.

 

If they can't be bothered to clean up unused variables, would they be bothered to write good code that doesn't break? It's risky enough using third party stuff as is, the least I would do is not use stuff that was obviously poorly maintained, unless I was going to fix it up and maintain it myself.

The idea of suppressing warnings to me sounds like a terminally bad idea.

 

terminally bad idea.. lol what you gonna say next, the suppression of cs3001 could lead to the apocalypse .... some people just live life prioritizing what is actually important dude

 

The way I see it, it's bad enough having issues that lead to warnings, but it's infinitely worse suppressing them. It's the beginning of the end, the road to perdition, that moment where a soul began its journey into darkness.

Actually, probably nothing so dramatic, more likely just the slow death of a codebase, and one's motivation to work with it.

 

Most ignorance is willful.

 

That's true.. now apply it to something in life that actually matters

 

I agree with this so much.