in reply to Turn off warnings, diagnostics?
I'd certainly turn off diagnostics. No point engaging all of that machinery in order to repeatedly verbosely explain every error and warning over and over again in the log.
I often support turning off warnings in many environments. But that depends on where the warnings go and are they likely to do any good. Warnings going to end-users is usually worse than a waste but also confusing and/or annoying.
Warnings going to the web server error log is often of little benefit but at little cost. There is a risk of a few pointless warnings getting logged at such a high frequency that they cause logs to fill disk or just make it unnecessarily cumbersome to notice, find, organize, or respond to more serious errors in the log.
There is also the chance for a developer to notice a warning in the log and from that figure out a subtle bug and fix it.
But I'd definitely not put "use warnings;" in your modules. Whether or not warnings are desirable depends on environment and so should be controlled by environment (with the caveat that there is a risk, small in my recent experience, of depending on somebody else's module that is sloppy about something that ultimately doesn't matter but that generates warnings when you enable them globally and yet you don't want to "fix" that warning because it isn't your module -- but a simple __WARN__ handler can usually easily plonk those).
Even more clear to me is that you should at least start with -w in the #!-line of your test scripts.
Whether to put -w in your web scripts is a harder call. Depends how likely developers are to make improvements due to those warnings ending up in the logs on that web server (I'd certainly turn on warnings in non-Production web servers and encourage routine review of web error logs by developers and QA) and how likely the warnings are to be voluminous enough to cause problems.
- tye