Yeah. Too bad some warnings are there because someone thought "I think this is bad coding style, let's issue a warning", and had their patch accepted. Luckely, most proposals like that never make it, but some did.

You shouldn't ignore a warning unless you have researched it and determined that you actually want to do whatever it is that's triggering the warning.

Yeah, but in most cases, it's bloody obvious.

THEN, you go ahead and document that this warning is expected and the reason why it's ok.

I think we have a fundamental difference in assumption about what code is and what it is not. My assumption is that the code I write is not mine in the way that my underwear is mine. I write code that part of a group's work. The stuff I type in will be edited by someone else and I will be editing code that someone else typed in.

With that in mind, I have to try to write my code as strictly as possible. This means turning on all strictures and warnings. Now, I have, do, and will write code with soft references in it, in violation of strict-refs. I have, do, and will write code that needs no warnings 'uninitialized'.

I suspect the difference between you and I is that I am directly accountable to other people. These people are extremely programmers, but I'm still accountable to them. So, I have to demonstrate why I feel that strict-refs or no-warnings is appropriate.

The thing I always return to is that the warning is describing a potential error condition. By turning off warnings, I'm turning off a error-detector. Sometimes, it is annoying, but it's saved my butt at 3am on Saturday more often than I'd care to admit.

My criteria for good software:

Does it work?

Can someone else come in, make a change, and be reasonably certain no bugs were introduced?