Whenever I take over a new project I immediately endeavor to fix all the warnings. The reason is simple: I've spent too much time chasing bugs that were directly related to a specific warning in a sea of them. Once you get a project warning-free it's quite easy to keep it that way.
Regarding the author's specific complaint--unused variables--I find that it's quite simple to comment out the declaration. There's no need to resort to pragmas in this instance.
Inflicting -Werror on yourself is fine, but inflicting it on others is onerous, because there's no way you can guarantee that your code produces no warnings on their compiler with their library and header versions.
This is precisely the reason it is in fact necessary.
When writing code that is intended to be portable and is expected to generate reproducible floating-point calculations in numerically intensive calculations, warnings on different platforms and header versions is a godsend.
When I receive a bug report that says, "I am using operating system distribution X, version Y, with library version Z, and specific test W produces warnings when I type `make check`," it makes me happy.
I would absolutely relax the constraint if I was maintaining a large cross-platform OSS project. In that case, I think your criticism is on point. I hadn't considered this situation as I've not been the maintainer of such a system.
The second situation is when you don't control the build process, in which case someone or someones are keeping you honest.
Certainly building with a tool like Xcode makes the warnings more conspicuous, and you can just choose to fix all warnings. I don't see anything wrong with that approach, but I still prefer to just treat the warnings as errors. I guess it's just how I'm built.:)
All that you see after that are warnings and errors.
Now, if dependencies were in order, and I'd just made a small change to a single file, and had previously built the project successfully, I'm sure I could probably catch a single warning. That's a lot of assumptions to work from. I prefer to let the build fail.
But then you have commented out code potentially forgotten about and checked in and no warning. That's the problem with universally enforcing a rule. Circumventing the rule is usually messier than just breaking it.
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.
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 ;)
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.
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.
On the projects I manage, warnings are unacceptable, and treated as errors. We will not release an update until it builds without warnings.
Using NS_REQUIRES_NIL_TERMINATION on a var args Objective-C method seems to cause a warning "Attributes on method implementation and its declaration must match" — despite both the declaration and implementation being exactly the same.
Using uniqueIdentifier in debug builds (for TestFlight) triggers an API deprecation warning. Despite being OK to use for non-App Store iOS apps.
You also DON'T want to do -Wall and -Wextra along with -Werror. Why? Because when a later version of the compiler gets smarter and puts in more warnings, suddenly your (working) code won't compile anymore! That would go over very poorly in a CI system or an open source library! Your "future proofing" has just ensured that sometime down the road (and likely at an inconvenient time), your project is guaranteed to break!
Firstly, when clang warns you of an error, it tells you the switch it uses to highlight that error, the disabling flag is then "-Wno-$switch" (or simply use a clang pragma to disable the warning: http://stackoverflow.com/questions/7017281/performselector-m...)
Secondly, the errors reported by -Wall and -Wextra are likely to be program bugs / bugs further down the line.
Thirdly: I upgraded my compiler on my CI system, I'd damn well want to know about new errors!
These days, clang will tell you what a warning is called any time it gives you one. If you ever need to disable a warning, make it happen (which you probably already did, otherwise why would you need to disable it?) and then just read the error message to see what flag to use to disable it.
I have another guideline that I frequently apply: Don't update your tools if you're close to cutting a new release. This mitigates the risk of unexpected build issues a the worst possible time.
It is the only sane way to give C and C++ the same strong typing that other languages enjoy since birth.
Quite useful in projects where due costs, most developers are not that experienced.
I am yet to do a Objective-C project, but I would use the same approach.