Well, the answer from "received wisdom" is that maintenance
often involves adding or modifying functionality, which
may entail using new variables, and if there's no clear
pattern for making up variable names, and you're not paying
attention, ... etc.
But your point is well taken, and it's worth noting
that even without "use strict", you can still declare
variables with "my" to get the intended effect of scoping,
just to make sure a newly added variable doesn't trounce a "legacy"
variable that happens to have the same name. | [reply] |
Hmmm.. IMHO, it depends on the forseeable future such a script will be exposed to. If you know you will change/add to the script again, I'd rather start using strict sooner than later... If that, however, keeps me from accomplishing my work at the time I planned, I'd chuck it, without second thought, too.
Regardless of that, if I'd inherit maintenance of someone else's obsolete script, the first thing I'd do anyway is to work through the code (most likely making lots of changes). And I'd be sure to cure it from overuse of local, no matter whether I use strict or not.
It's not about blindly obeying the strict dogma -- it's about bringing the script up to date.
So long,
Flexx
| [reply] |
In many instances I would view this question as a good one simply because I think that traditions, which many who ask this same question might also view the use of 'use strict' as a pragmatic tradition for which there is no real good reason to use it other than 'everybody else does it', should be questioned now and then. However, it has been stated many times past and now present (again) the purpose of use strict in all its glory (tm).
Clean coding practice not only helps you but it helps those who maintain your code after you. If 'use strict' complains about something, fix it! Don't just stop using strict :). There is a reason such tools are available to us to use. Alas, to each his own. I methodically make use of the use strict pragma and I am grateful that it is there for me to use.
If there is something specifically in your code that you don't want to use strict for then turn strict off for that bit of code and then turn it back on afterward :). I'd make sure I would comment why I am turning it off, though. That could be very useful to the maintainers.
Anyway, that is my $.02 cents. Thanks!
_
_
_
_
_
_
_
_
_
_
- Jim
Insert clever comment here... | [reply] |
Thanks for your reply.
Up to now, I have not used 'use strict' for the very reasons you cite. Besides that, it appears to slow the script down tremendously (this may be due to the warnings). After I'm done with 'use strict', I am considering commenting the line so the script will load quickly again.
The script has a difficult to find intermittent defect. So, I'm employing 'use strict' to help find bad habits and maybe even help find this or some other defects.
I'm a C++ programmer by trade and because of the nature of C++, I try to let the C++ compiler find defects for me as often as possible. In this instance, I'm employing the same approach to Perl.
Richard | [reply] |
