I guess I don't understand your complaint. I'm not talking about commenting out huge swaths of code to avoid warnings. And I'm certainly not advocating committing such code. (Or, let me be more clear, I'm not advocating publishing such code. I think it's fine to commit it to a local branch, but the code should be clean by the time it's merged to a public branch.)
But, if you've prematurely declared a variable and find it's throwing a warning, I see no issue with temporarily commenting out the declaration. The only downside I can think of is someone accidentally commits a single-line, commented out variable declaration.
I can say I rarely run into this specific problem. I tend to use variables once they're declared. It's possible my development style is just different. If I found this to be a big problem, I probably would disable the warning for debug builds.
I've had this sort of problem quite a bit, but it probably does depend on programming style. If you use a lot of temporary variables rather than anonymous subexpressions (this is somewhat common among people who use a debugger a lot, and some compilers seem to prefer SIMD code to look like this) then it's very easy for one commented-out line to turn into a whole pile of unused variable warnings that slowly fan out as you "fix" each one in turn (because many expressions simply combine two variables that themselves only exist to be inputs for that expression, and so on in turn). This is terribly galling if you're only commenting something out as a quick (or not, as it turns out...) sanity check while you're trying to debug something.
All in all, warnings-as-errors seemed to me like a bum deal. People who don't fix their warnings without warnings-as-errors can't generally be relied on to fix them properly; people who do fix their warnings would have fixed them anyway; everybody is annoyed at some point.
In fact, I am actually becoming annoyed just thinking about it again ;)
And I'm annoyed when there are hundreds of innocuous warnings. In that case I have to mentally track the warning count so I know when I've incremented it.
Someone who can't fix a warning properly probably isn't a very good coder to begin with. I'd say you're hosed no matter what. :P
I understand you problem with lots of temporary variables. It's not a situation I've encountered. It's certainly something that might make me reassess my position should I encounter it.
> The only downside I can think of is someone accidentally commits a single-line, commented out variable declaration.
Yeah, that's the sort of thing I was thinking of. Or empty method implementations, or dummy return values, or whatever.
I guess my point is just that if it's more convenient to do something else before fixing an issue, then it's better to have a warning reminding you to fix it than to not. And if you're not going to circumvent the error, you're probably not going to ignore the warnings either.
Reading your other comment, you mentioned working with make. The advantage I mentioned only really applies in IDEs.
But, if you've prematurely declared a variable and find it's throwing a warning, I see no issue with temporarily commenting out the declaration. The only downside I can think of is someone accidentally commits a single-line, commented out variable declaration.
I can say I rarely run into this specific problem. I tend to use variables once they're declared. It's possible my development style is just different. If I found this to be a big problem, I probably would disable the warning for debug builds.