in reply to local vs my

Here's a question: why the obsession with 'use strict' in a script that already works and you're just maintaining?

If 'use strict' doesn't do what you want, chuck it. Get what you need from warnings, strict 'subs' and strict 'refs'. Ignore the peer pressure telling you that everything has to 'use strict'. It doesn't.

Replies are listed 'Best First'.
Re: Re: local vs my
by graff (Chancellor) on Sep 03, 2002 at 03:22 UTC
    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.

Re^2: local vs my (when to use strict, inheriting maintenance)
by Flexx (Pilgrim) on Sep 03, 2002 at 10:08 UTC

    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,

Re: Re: local vs my
by snafu (Chaplain) on Sep 03, 2002 at 16:31 UTC
    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...

Re: Re: local vs my
by Anonymous Monk on Sep 04, 2002 at 11:08 UTC
    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.