I respectfully disagree. Unused variables can be a sign that the developer has misspelled something. That strikes me as being quite useful.

This thread has been necroed just to post a rant. Closing.

You know I actually wished more languages took the approach of not allowing warnings to be suppressed (or at least developers were forced to deal with them). Think about what a warning is (at least in languages like C and C++). A warning is something the compiler author feels needs to be brought to your attention. Maybe you’re intentionally casting a 64-bit integer to a 32-bit unsigned integer (to offer one ridiculous example) which is legal but maybe not what you meant to do.

I love the fact that the same people who insist on 100% test coverage never bother to turn the warning level to 4 and never bother to have their warnings treated as errors. To me this is a simple, cheap way to catch potential bugs at compile time. Sorry–I’m digressing.

You’re facing the result of 7 years of people not dealing with warnings. Yes, it’s a pain in the ass to deal with all those warnings when something you want to know about may be hidden but ignoring them is not really a great answer either.

I once saw a bug in some C++ code that came down to this:

if (x = 1) 
{

Of course what they meant to type was if(x == 1) and the compiler warned them about assignment in the conditional test but they had ignored compiler warnings (for years as far as I could tell). Something like this jumps right out when I type it on a line by itself but buried in thousands of lines of code, it’s a bit harder to catch. At any rate, I set the C++ compiler to treat warnings as errors and this popped right out.

Ignoring warnings is a path to large chunks of technical debt (to say the least). Bite the bullet and get rid of the warnings that have built up over 7 years. I suspect the reason you don’t want to deal with the warnings is that you haven’t got time–tight deadline or something of that sort. But if you suppress or continue to ignore warnings you’re just kicking the can down the road. I mean how do you know that those warnings you’re trying to suppress aren’t pointing out real issues in your code?

Just my $.02.

I suppress warnings because I hate the recent IO diagnostic change that forces me to search for errors within a sea of warnings, instead of putting the error as the last line when the compilation terminates.

I knew this type of response would show up here like all the other places… Again, in a vacuum I agree with you. Warnings can be helpful. If I started a fresh project I would probably use the warning-as-error or whatever flag to help keep them from happening at all (however idk what you would do if you actually had an intentional warning).

We have been actively addressing them as we go. Typically if we touch a file that has some we address them. I don’t want them always suppressed, I want to optionally disable them. I love my IDE underlining it in yellow, I want CI showing it, I want to see it when I build sometimes too. I want the flexibility to leverage it when it’s useful and turn it off when it’s literally not useful.

I want to be pragmatic with my solution I have and not dogmatic about all warnings are or are not the enemy. I believe there is nuance in most things, this included.

It totally could be signs of “real” issues. But clearly not any major issues because they’ve been there for years and our system has served millions of users just fine with all of them there! Like worrying about an unused variable is hardly a cause for concern generally… and yes some very niche edge case it could help identify, but we are past the point of no return. To me there is a difference between like theoretically a problem and actually a problem, and most of our warnings are theoretically a problem.