I'm really hopped up at the office right now, in a losing holy war about using warnings in production... Probably not the best state of mind to compose a post, but I hope it spurs a fruitful discussion nonetheless.
Brother Monks, I ask you... Should warnings be enabled on production, yay or nay?
Due to the way our system is architected, it likes to crap out if a script generates a warning, but it will do so silently. There's no way for us to know if a script dived out because of a warning or successfully sent its output to the next system.
So my coworker is on a cleansing mission of sorts, to remove all warning switches from our scripts. I'm adamantly opposed to the idea, as use strict and use warnings are my best friends (as they should be yours).
Coworker #2 notes that I can have the best of both worlds, developing in warnings and sending out to production without warnings (see ENVIRONMENT or PERL5OPT in perlrun).
Our leading programmer agrees with both coworkers #1 and #2 that warnings cause more problems than they are worth. I maintain that really good code won't be generating warnings anyway.
Coworker #2 adds enabling warnings comes at a performance cost. Is this even true? I counter via absurdity that why don't we develop without use strict? Then our code would be lightning fast.
I'm adamantly opposed to running production code without warnings. I think programmers should take more responsibility on the warnings they helped generate. And I think everyone in the office is wrong. Except me.
Monks, I bid you good day. May your code be speedy and true.
In reply to Warnings and Strict in Production/Performance by deep submerge
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |