Without strict you can explore and try things more quickly and easily. If you use strict, then you have to write quite a bit of boilerplate, like variable declarations, which you are most likely going to have to remove later anyway, as you work your way through the problem and alter your approach.
Basically, without strict you can get a working prototype much faster. Then you can add strict and all the usual boilerplate when you're done.
Though I must admit I like that poem... :-)
| [reply] |
That goes completely against my experience (15+ years with Perl). The only "boilerplate" required by strict is to declare variables which typically consists of three extra characters - that is not onerous.
Best practice is to only declare variables in the scope they are used and to initialize them when they are declared. In your sample code that amounts to 28 extra characters counting the "use strict;" statements. That is about a 2% overhead. 2% does not equate to "much faster" in my book.
"running prototype" != "working prototype". A simple typo in a variable name that strict would have alerted you to can easily soak up tens of minutes of debugging time or introduce subtle calculation or logic errors that may go unnoticed. Just one case like that detected by strictures will more than outweigh the trivial overhead of the "boilerplate" over tens of projects.
Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond
| [reply] |
I've already explained why it helps, and I'm not lying when I say it does help. Perl is the language of AND rather than OR, and there is more than one way to do it, so I personally don't value categorical imperatives about best practices too highly.
(Also, perl -w warns you if you only use a variable once, so I don't think your example is valid. Of course, if you misspell it the same way twice, then you have problems.)
| [reply] |
