I know this is being pedantic,

No, it isn't. It's merely being opinionated. This reply is pedantic...

According to Merriam-Webster, an appropriate definition of "pedantic" in this usage would be "of, relating to, or being a pedant." Its root is defined variously as one who makes a show of knowledge, one who is unimaginative or who unduly emphasizes minutiae in the presentation or use of knowledge, or a formalist or precisionist in teaching.

I find that using strict after development is over and when code is "live" is usually the most useful.

Most of the errors that strict provides are compile time errors. The exception is a runtime error when you use symbolic reference under strict 'refs'. So, unless you have evals (the expression form) or are using /ee on regexes and propogating the errors in $@, strict is limited in its usefulness in "live" code.

That doesn't mean I don't leave it on; I generally do. But its benefits are definitely more pronounced during development. Besides, if your "live" code is generating errors because of strict checking, then development isn't exactly "over", now is it?

Sure it's nice to have in development, but as much testing as I can do it's when stuff is live that I really want to see comprehensive, readable, error messages.

Using strict doesn't change the quality of the error messages you get. Perhaps you are thinking about use diagnostics? Strict checking causes more conditions (the ones you usually want to avoid) to be reported as errors in the first place. Enabling warnings does exactly the same thing but results in warnings rather than errors.

BTW, if you aren't testing before the code is "live", then you are testing while it is live. Maybe what you are really saying is that you find these pragmas most useful during testing...

-sauoq
"My two cents aren't worth a dime.";